This is meant to save us in cases where the message loop in GPU process
receives commands related to resources that point to the old EGL context
that was just shut down. Since the symbols are erased, we'd end up with
trying to execute a nullptr on `MakeCurrent()`. With marking the context
as lost, however, no symbols will be accessed.
Differential Revision: https://phabricator.services.mozilla.com/D84868
Simple implementation of skipping SyncObjectD3D11Host::Synchronize(). More optimization could be done in Bug 1635629.
Differential Revision: https://phabricator.services.mozilla.com/D75781
When DWM is disabled, each window does not have own back buffer. They would paint directly to a buffer that was to be displayed by the video card. WM_PAINT via SendInvalidRegion() requests necessary re-paint. With it, RenderCompositorANGLE does not need to disable partial present.
Differential Revision: https://phabricator.services.mozilla.com/D77989
Do full render with WebRender when Dwn is disabled. It could be done by RenderCompositorANGLE::RequestFullRender().
Back out Bug 1638469. It disables WebRender during starting if Dwm is disabled. But Dwm is enabled/disabled dynamically. And we do not want to disable WebRender in this case.
Differential Revision: https://phabricator.services.mozilla.com/D77221
With current gecko, there are cases that compositor window is used even when it is not necessary. For example, fallback from DirectComposite with WebRender and fallback from double buffering with Compositor. With some gpu drivers, the fallbacks with compositor window causes rendering problem.
Differential Revision: https://phabricator.services.mozilla.com/D76470
In the past EGL only supported GLES, not OGL. This has not been true
for a very long time, so lets support OGL context creation in the EGL
backend.
This allows e.g. the Wayland backend to use OGL contexts, which brings
it on par with the X11/GLX backend.
Differential Revision: https://phabricator.services.mozilla.com/D48096
WebRender could be used when WebRender does not use ANGLE. And there is a case that we want to use WebRender with ANGLE for testing.
Differential Revision: https://phabricator.services.mozilla.com/D69771
--HG--
extra : moz-landing-system : lando
This adds support for tracking and invalidating tiles based on a
movable virtual offset.
Differential Revision: https://phabricator.services.mozilla.com/D65687
--HG--
extra : moz-landing-system : lando
Use ThinVec instead, which is compatible with nsTArray, and makes stuff much
harder to misuse.
Differential Revision: https://phabricator.services.mozilla.com/D63256
--HG--
extra : moz-landing-system : lando
For Draw (non-native) and CA modes, we include the per-tile
valid rect in the clip rect from the surface.
For DC (non-virtual) mode, a per-tile clip rect is set on the
visual for each tile, separate from the overall clip rect that
is set on the surface visual.
For DC (virtual) mode, the Trim API is used to remove pixels
in the virtual tile area that are outside the valid / clipped
region.
Note: Although the valid rect is now applied in the native
compositors, it's currently only based on the overall picture
cache bounding rect. Thus, with this patch there isn't any
noticeable performance improvement. Once this lands and is
working correctly, the follow up patch to calculate a smaller
valid region per-tile is a small amount of work.
Differential Revision: https://phabricator.services.mozilla.com/D61424
--HG--
extra : moz-landing-system : lando
SyncObjectD3D11Host::Synchronize() calling in RenderCompositorANGLE::BeginFrame() is still necessary for D3D11DXVA2Manager::CopyToImage(). Then backout Bug 1596630.
Differential Revision: https://phabricator.services.mozilla.com/D61658
--HG--
extra : moz-landing-system : lando
This will allow use of the DirectComposition virtual surface API. If
it turns out that some pages recreate surfaces a lot due to opacity
changing, we can add some extra logic to avoid recreating surfaces
as often, and making use of per-tile opacity in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D57592
--HG--
extra : moz-landing-system : lando
about:support could have an information that WR compositor is disabled by disabling picture caching.
Differential Revision: https://phabricator.services.mozilla.com/D57266
--HG--
extra : moz-landing-system : lando
wr::WebRenderPipelineInfo needs to be handled even when WR rendering does not happen.
Differential Revision: https://phabricator.services.mozilla.com/D55899
--HG--
extra : moz-landing-system : lando
mSyncObject->Synchronize() was necessary to handle a case that D3D Texture was created on main thread of content process and the Texture does not have a keyed mutex. But with WebRender, the situation does not happen often. Further the Synchronize() is sometimes very slow. Therefore it is better to remove it from RenderCompositorANGLE::BeginFrame().
Canvas 2d does not use keyed mutex yet. Then the change adds keyed mutex usage for the canvas 2d.
D3D11DXVA2Manager still uses the Synchronize(). In this case, the Synchronize() is manually called in D3D11DXVA2Manager::CopyToImage(). Then RenderCompositorANGLE still needs to create SyncObjectHost.
Differential Revision: https://phabricator.services.mozilla.com/D53168
--HG--
extra : moz-landing-system : lando
During high contrast mode, alpha is used by SwapChain. In this case, IDXGISwapChain1::Present1() shows nothing with compositor window. To address the problem, we disable the Present1() usage when alpha is used.
Differential Revision: https://phabricator.services.mozilla.com/D52511
--HG--
extra : moz-landing-system : lando
LayerManagerComposite and LayerManagerMLGPU do full rendering for taking a snapshot. Then WR also does full rendering for taking a snapshot.
Differential Revision: https://phabricator.services.mozilla.com/D51775
--HG--
extra : moz-landing-system : lando