The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
This patch is plumbing to get a path and a flags word through from the content
process to the graphics process, to pass to `wr_api_start_capture_sequence`.
Differential Revision: https://phabricator.services.mozilla.com/D106229
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
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
In order to hit the fast path in ANGLE for readback from the
DirectComposition surface tiles, we need to ensure it uses
the same format as intermediate surfaces we are reading back to.
DirectComposition docs claim that both RGBA8 and BGRA8 formats
are supported for surfaces, and doesn't mention any performance
concerns.
I did some basic testing on an NVIDIA GTX 1050 and an Intel
HD530 and didn't notice any performance difference in Gecko
or in DWM.
This patch lands just the format change, so we can easily detect
any correctness or performance issues from the format change.
Differential Revision: https://phabricator.services.mozilla.com/D104771
Previously, we've taken the strategy of exposing any gecko specific hooks
as traits. The disadvantage of this approach is that it requires plumbing
a boxed trait through to any places that need to use it.
With this approach, we add global functions that don't do anything when
compiled without the 'gecko' feature. This makes it easier to add hooks
and avoids the plumbing which should reduce friction in the process
of moving more stuff out of gecko and into webrender.
Differential Revision: https://phabricator.services.mozilla.com/D102334
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
