We keep encountering issues on various platforms due to the usage of
switch statements, especially the optimized output produced by
glslopt. Replace all instances with if-else statements instead.
Differential Revision: https://phabricator.services.mozilla.com/D103300
This change remove the files used for building and testing vrhost.dll, which was used for an early prototype of Firefox Reality PC.
This binary is no longer needed for FxR PC.
Differential Revision: https://phabricator.services.mozilla.com/D103237
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
GL_ARB_clear_texture implements some useful GL entry-points for clears
that can clear arbitrary sub-rects of the screen without having to latch
or disturb GL state. This refactors the glClear implementation to be in
terms of the provided glClearTexSubImage extension which is far more
flexible.
This further allows us to reuse clearing primitives in RenderCompositorSWGL
without having to use more expensive DrawTarget versions.
Differential Revision: https://phabricator.services.mozilla.com/D103252
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
GL_ARB_clear_texture implements some useful GL entry-points for clears
that can clear arbitrary sub-rects of the screen without having to latch
or disturb GL state. This refactors the glClear implementation to be in
terms of the provided glClearTexSubImage extension which is far more
flexible.
This further allows us to reuse clearing primitives in RenderCompositorSWGL
without having to use more expensive DrawTarget versions.
Differential Revision: https://phabricator.services.mozilla.com/D103252
Combobox select has the block-axis padding in the comboboxcontrol frame.
Moving it fixes bug 1560824 and should be better, so will do that there.
1px block axis padding on buttons matches Chrome too, so shouldn't be a
problem compat-wise.
Differential Revision: https://phabricator.services.mozilla.com/D103244
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
GL_ARB_clear_texture implements some useful GL entry-points for clears
that can clear arbitrary sub-rects of the screen without having to latch
or disturb GL state. This refactors the glClear implementation to be in
terms of the provided glClearTexSubImage extension which is far more
flexible.
This further allows us to reuse clearing primitives in RenderCompositorSWGL
without having to use more expensive DrawTarget versions.
Differential Revision: https://phabricator.services.mozilla.com/D103252
Currently when the GPU cache is resized we allocate a new texture and
then copy the contents of the old texture to the new texture. This
copy requires either EXT_copy_image (for glCopyImageSubData) or
EXT_color_buffer_float (to bind the RGBAF32 texture to a framebuffer).
On devices where neither extension is supported, don't attempt to copy
the old texture. Instead mark the entire CPU-side copy of the cache as
dirty, meaning we will subsequently upload the entire contents to the
new texture. (A complete CPU-side copy is only mainted for the
PixelBuffer gpu cache bus type, not for Scatter ones. However, as the
Scatter type also requires EXT_color_buffer_float, we will only be in
this situation for PixelBuffer buses.)
Differential Revision: https://phabricator.services.mozilla.com/D103071
Instead of keeping a stacking context around for scrollbar containers,
extend and use the tile cache barrier code to create them. This
removes the final remaining code path that creates pass through
picture primitives.
The tile cache barrier changes also form the basis of how we will
make blend containers and backdrop roots work in a follow up patch.
Blend containers and backdrop roots will become redundant stacking
contexts when they exist at the start of a tile cache, which will
save an entire off-screen surface / constant invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D102527
Previously, a leaf picture would be created unconditionally when
popping a stacking context during scene building. This results in
many pass-through pictures being created that are often not required.
This patch introduces a helper struct that delays creation of a
pass-through wrapping picture until it's known to be needed (and
instead adds the prim_list to a wrapping picture where possible).
In a follow up patch, the last couple of places that create pass
through pictures via pop_stacking_context will be removed.
Differential Revision: https://phabricator.services.mozilla.com/D102381
It appears that the slight refactoring of blend_pixels from the clip-mask
optimization in bug 1688104 caused clang-cl to inline blend_pixels more
pessimistically than it was doing before. Since this is an extremely hot
function that all alpha-pass rendering relies on, we generally just want
to inline this regardless of the slight increase in compile size since
a failure to aggressively optimize this can have noticeable performance
impacts.
Differential Revision: https://phabricator.services.mozilla.com/D103033
This patch enables EGL robustness with WebRender. It also tries harder
to get RBAB, favouring KHR+RBAB over EXT-RBAB, as testing with Intel and
NVIDIA Mesa drivers on Ubuntu suggests we can get KHR+RBAB but not
EXT+RBAB. It also adds support for requesting NVIDIA specific resets via
EGL_NV_robustness_video_memory_purge.
Differential Revision: https://phabricator.services.mozilla.com/D102971
When CompositorHwnd does not exist, FLIP_SEQUENTIAL could not be used, since it could cause a problem like Bug 1435995. For example, CompositorHwnd creation could be failed on Win7.
Differential Revision: https://phabricator.services.mozilla.com/D102531
Not all configurations have both libGL and libGLES present, and this
matches the order which glxtest loads them. Without this, a user might
pass glxtest, which says they can use EGL, but then not have libGLES on
the library path.
Differential Revision: https://phabricator.services.mozilla.com/D102936
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140