The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
SurfaceDescriptorGPUVideo, which currently only represents RemoteDecoder video, switches from being a struct to a union that holds a SurfaceDescriptorRemoteDecoder struct. SurfaceDescriptorRemoteDecoder is a new name for the old SurfceDescriptorGPUVideo. This is done so that we can later add SurfaceDescriptorPlugin as another type of SurfaceDescriptorGPUVideo.
Differential Revision: https://phabricator.services.mozilla.com/D52400
--HG--
extra : moz-landing-system : lando
This patch include two performance improvements:
- Only rebuild the DC visual tree if different from last frame.
- Use EGLImage instead of pbuffer for DC <-> GL interop.
These fix most of the talos regressions with DC enabled in WR.
Differential Revision: https://phabricator.services.mozilla.com/D53916
--HG--
extra : moz-landing-system : lando
MigrateToActiveGPU is only called on compositor GLContexts, not for WebGL.
See bug 1597547 for WebGL.
After this fix, the situation can be improved in multiple ways:
- Rather than moving contexts between GPUs, it would be better to have separate
contexts for each GPU, and teach our compositors to switch a window over to
a new context.
- Instead of creating a fresh context to obtain the "preferred" GPU, we should
find the GPU that drives the display on which the context's results are going
to be displayed.
Differential Revision: https://phabricator.services.mozilla.com/D53719
--HG--
extra : moz-landing-system : lando
This setting was only respected for manually-created fake "default" framebuffers,
by code that no longer exists.
Differential Revision: https://phabricator.services.mozilla.com/D52922
--HG--
extra : moz-landing-system : lando
This depth buffer would only be created for the default framebuffer, but there is
no default framebuffer on macOS (since all rendering goes into IOSurfaces), so
this attribute is ignored.
We already manually create depth buffers for the IOSurface framebuffers.
Differential Revision: https://phabricator.services.mozilla.com/D52921
--HG--
extra : moz-landing-system : lando
This seems to be what other platforms do. FORCE_ENABLE_HARDWARE is controlled by the pref webgl.force-enabled.
gl.require-hardware was only read on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D52920
--HG--
extra : moz-landing-system : lando
This distinction is not meaningful with CoreAnimation because all rendering happens into IOSurfaces.
Differential Revision: https://phabricator.services.mozilla.com/D52919
--HG--
extra : moz-landing-system : lando
EGL_ANGLE_experimental_present_path was enabled for fast rendering to SwapChain by ANGLE. But current gecko does not request ANGLE to render to SwapChain for WebRender. Then we do not need to use EGL_ANGLE_experimental_present_path anymore. But Its usage still has a side effect that y is flipped. But OS compositor implementation on Windows does not want it. And it seems not good to continue to use EGL_ANGLE_experimental_present_path since it is experimental feature.
But when EGL_ANGLE_experimental_present_path is removed, rendering result of frame buffer is y flipped with ANGLE compared to other OpenGL implementation. It needs to be handled in WR. It is similar to chromium.
Differential Revision: https://phabricator.services.mozilla.com/D50604
--HG--
extra : moz-landing-system : lando
This essentially backs out the two patches from bug 1565668 that added this
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D44330
--HG--
extra : moz-landing-system : lando
This returns the raw framebuffer GLuint and lets the caller bind it.
Initially I wanted to return a RefPtr<MozFramebuffer>, but then I discovered
that MozFramebuffer is not a refcounted class and prefers UniquePtrs.
Depends on D44324
Differential Revision: https://phabricator.services.mozilla.com/D44325
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
