This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
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
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
+ 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
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
This removes the last use of DefineClip from Gecko, which will
allow removing and simplifying a lot of the clip handing code
during scene building in WR.
Differential Revision: https://phabricator.services.mozilla.com/D118121
+ 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
This was introduced in D106246. Most likely it is only necessary
on uncomposited legacy desktops. So on Linux only enable it for X11,
leaving out Wayland.
Removing it makes `RenderCompositorSWGL` behave (more) equally to
`RenderCompositorOGLSWGL`, massively reducing overpaint on certain
websites like testufo.com and improving frame rates on many low-end
devices.
Differential Revision: https://phabricator.services.mozilla.com/D118192
Instead of drawing updates into the correct spot in the destination
DataSourceSurface we just use it as scratch space and always
draw in the top-left with stride = bpp*width.
We add a dstOffset to the upload functions to support using
a subsurface.
Differential Revision: https://phabricator.services.mozilla.com/D116501
+ 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
Building on previous patches, this adds a preference to enable
a low quality pinch-zoom mode that reuses cached tiles where
possible.
It doesn't currently redraw at the higher quality scale at the
end of a pinch-zoom, and there are some sampling artifacts in some
cases. However, it should be enough to do some performance testing
on low and devices and see if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D117497
Reject software rasterizers on Linux (except Software WebRender) when
trying to create full WebRender, unless WebRender was force enabled.
Differential Revision: https://phabricator.services.mozilla.com/D117534
Analogous to D102835 we need to make GDK aware of opaque surfaces
so frame callbacks get emitted for these surfaces as well. Otherwise
GDK may get stuck waiting on callbacks when used on compositors
that don't emit callbacks for occluded surfaces (which is explicitly
encouraged by the Wayland spec).
GDK runs on the main thread, so we need to dispatch these action
to the main thread as well.
Differential Revision: https://phabricator.services.mozilla.com/D116747
Analogous to D102835 we need to make GDK aware of opaque surfaces
so frame callbacks get emitted for these surfaces as well. Otherwise
GDK may get stuck waiting on callbacks when used on compositors
that don't emit callbacks for occluded surfaces (which is explicitly
encouraged by the Wayland spec).
GDK runs on the main thread, so we need to dispatch these action
to the main thread as well.
Differential Revision: https://phabricator.services.mozilla.com/D116722
This passes the swgl context down from the renderer
instead of using the current context. This ensures
we report all of the contexts and don't double report.
Differential Revision: https://phabricator.services.mozilla.com/D116474