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
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
mCompositor->BeginFrameForWindow() needs to be called for ScreenshotGrabber::MaybeGrabScreenshot() with CompositorD3D11.
Differential Revision: https://phabricator.services.mozilla.com/D114714
When render_impl is called from update, the device_size is None, and so dirty rect calculation is skipped. Then if RenderCompositorLayersSWGL does not handle start compositing when dirty rect does not exist, we could ignore StartCompositing() from update.
Differential Revision: https://phabricator.services.mozilla.com/D111583
The backend CompositorD3D11/CompositorOGL layers compositors can already do
partial clear optimizations for us if applicable. The only thing we need to
do is pass in the actual dirty/opaque regions so that it can utilize it.
Like with RenderCompositorSWGL, we move the actual allocation of the framebuffer
into StartCompositing when this information is known, rather than BeginFrame
which is too early in the frame to have this information yet.
Differential Revision: https://phabricator.services.mozilla.com/D109092
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
This requires us to plumb CompositorCapabilities to support the extra field.
This is complicated by the fact that since it is a Rust struct, it has no
default constructor that can pass through to C++ via bindings, so every
one of our RenderCompositors was forced to manually initialize fields. To
get around this brittle footgun, instead the structure is initialized on
the Rust side, and RenderCompositor's are encouraged to only change fields
that actually diverge from the defaults as passed in via pointer.
Finally, we can then do what we need to do, which is just to send the
ForceRedraw message that needs to happen based on what we know about
CompositorCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D106246
Jamie Nicol
Sandor Molnar
sotaro
Nicolas Silva
Csoregi Natalia
Butkovits Atila
Robert Mader
Lee Salzman
Andreea Pavel
Mihai Alexandru Michis