Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
We sometimes see webrender renderer initialization failing due to an
invalid max texture size being reported. The logcat shows that there
is no current GL context, and as a result glGet returns 0 when
querying the max texture size. This occurs after the
AndroidSharedBlitGL context has been destroyed on the renderer thread,
leaving no context as current.
This patch adds a call to MakeCurrent() for the renderer's OpenGL
context prior to renderer initialzation. This means we successfully
query the texture size and avoid the initialization error.
Differential Revision: https://phabricator.services.mozilla.com/D119334
When calling nsDOMWindowUtils::SetResolutionAndScaleTo in a test it's possible to have a layers update that only updates the zoom and nothing else. NotifyLayersUpdated will update the zoom but not the expected gecko metrics when this happens.
Differential Revision: https://phabricator.services.mozilla.com/D119248
When picture cache tiles were changed to be raster roots, this
broke quantizing of glyph sizes based on current scale. Restore
this behavior for high-quality pinch-zoom mode, and also select
the correct fixed scale for low-quality zoom mode.
Differential Revision: https://phabricator.services.mozilla.com/D119145
Previously, the child primitives of off-screen surfaces were not
being atomically treated as a single unit. This meant that the
primitives may be assigned to different sub-slices, under certain
edge case conditions.
As a short term fix, let the picture cache code know when an off
screen surface is being processed during primitive dependency
updates. This ensures that all child primitives within a surface
will be assigned to the same sub-slice.
Differential Revision: https://phabricator.services.mozilla.com/D119052
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
This follows what we're already doing for EGL: a refcounted object
which can own the X connection, where we hold a weak reference from
the library object so that multiple contexts opportunistically share
the display but we close the connection when the last context is
freed/GCed.
In a process where GTK is initialized, we borrow its display instead of
opening a new one, which preserves the existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112195
This is useful for debugging problems on systems such as android
or windows which can sometimes be tricky to get reliable console
output logging.
Differential Revision: https://phabricator.services.mozilla.com/D118772
Copy tiles data when tiles are opaque instead of blending them.
RenderCompositorLayersSWGL always blends tiles as premultiplied tiles. But it could not handle clear tiles and caused Bug 1718497. The problem does not happen with RenderCompositorSWGL. It copies tile data when tile is opaque. Then, RenderCompositorSWGL handles clear tiles correctly.
Differential Revision: https://phabricator.services.mozilla.com/D118953
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Now that picture cache tiles are raster roots, their scale is
expressed via the device-pixel scale. This means the calculated
scale can be too small when zoom factor is < 1 and a pinch-zoom
is currently active.
This is not a complete fix, it's an interim improvement until we
implement a proper fix. A complete fix will need to include the
device-pixel scale in the quantization process. However, this will
take some time to get right, since the existing code for selecting
a glyph size is quite complex due to different permutations and
how that code has evolved.
Differential Revision: https://phabricator.services.mozilla.com/D118781
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
Updating raster_scale in post_update can mean that it is
updated one frame too late. This can cause reftest failures
in tests that set the scale factor (without an APZ) and then
capture that frame.
Differential Revision: https://phabricator.services.mozilla.com/D118672
This ensures we get the correct advances for the variation settings that are in use,
not just the font's "default" advances from the hmtx table.
(I'm sad there wasn't a testcase that detected this regression, so added one here.)
Differential Revision: https://phabricator.services.mozilla.com/D118571
Fixes a case where at the end of a pinch-zoom on the Draw compositor
the tiles would be drawn incorrectly (due to the transforms not
being quite right for the local-to-surface case here, which was
affecting the occlusion calculations).
Differential Revision: https://phabricator.services.mozilla.com/D118559
In bug 1717519 we're seeing access violations when writing
to the destination with SWGL. This does some early writes
to try to catch the problem earlier.
Differential Revision: https://phabricator.services.mozilla.com/D118556
Florian Quèze
Jamie Nicol
Timothy Nikkel
Sandor Molnar
Markus Stange
Jonathan Kew
Glenn Watson
Jed Davis
Nicolas Silva
Hiroyuki Ikezoe
sotaro
Dzmitry Malyshau
Cosmin Sabou
Jeff Muizelaar
Jeff Gilbert
Robert Mader
Brindusan Cristian
Iulian Moraru
Emilio Cobos Álvarez
dev
Boris Chiou
Botond Ballo
Andrew Osmond