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
This replaces mUpdatesCount in AsyncImagePipelineManager, which was really how
many times NotifyPipelinesUpdated was called with aRender == true. I think this
makes the release logic clearer as it is more explicit.
It also changes things for RenderCompositorANGLE, so that we check to see if
any other frames have completed even if we don't want to wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D51064
--HG--
extra : moz-landing-system : lando
The patch permits to resize compositor window's size after ::SetParent() call to prevent a conflict between ::SetParent() and ::SetWindowPos(). Then it triggers a composite after SetParent() call to resize compositor window correctly.
Differential Revision: https://phabricator.services.mozilla.com/D49884
--HG--
extra : moz-landing-system : lando
This implementation is off by default (behind gfx.webrender.compositor) until various bugs and inefficiencies are fixed.
Differential Revision: https://phabricator.services.mozilla.com/D51034
--HG--
extra : moz-landing-system : lando
The patch permits to resize compositor window's size after ::SetParent() call to prevent a conflict between ::SetParent() and ::SetWindowPos(). Then it triggers a composite after SetParent() call to resize compositor window correctly.
Differential Revision: https://phabricator.services.mozilla.com/D49884
--HG--
extra : moz-landing-system : lando
Since Bug 1570879, SwapChain is created with alpha at first, then the SwapChain is typically re-created at first RenderCompositorANGLE::BeginFrame() calle, since non Glass window is common since Windows 10. The re-creation is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D48800
--HG--
extra : moz-landing-system : lando
When high contrast mode is enabled, title bar is drawn as transparent and on-client area rendering by DWM is shown. But when compositor window in GPU process is used, the on-client area rendering was not shown. To address the proboem, window needs to be cleard as transparent and SwapChain of compositor window needs to be DXGI_ALPHA_MODE_PREMULTIPLIED.
WinCompositorWidget::mTransparencyMode is changed to atomic, since it is accessed from compositor thread and render thread.
Differential Revision: https://phabricator.services.mozilla.com/D48302
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Preparation work for adding DirectComposition support. It does not add a new functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46429
--HG--
extra : moz-landing-system : lando
IDCompositionDevice::Commit needs to be called when there is an update to DirectComposition. RenderCompositorANGLE updates DirectComposition only during initialization. Then it is not necessary to call the function in EndFrame().
Differential Revision: https://phabricator.services.mozilla.com/D46249
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
When Windows version is mort than 1903 and GPU is intel GPU, it could cause flickering with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. See Bug 1556634. As a short term workaround, use DXGI_ALPHA_MODE_PREMULTIPLIED instead of DXGI_ALPHA_MODE_IGNORE at SwapChain.
Differential Revision: https://phabricator.services.mozilla.com/D41713
--HG--
extra : moz-landing-system : lando
Glenn Watson
Emilio Cobos Álvarez
sotaro
Jeff Muizelaar
Mihai Alexandru Michis
Glenn Watson
Csoregi Natalia
Bob Owen
Markus Stange
Bogdan Tara
Narcis Beleuzu
thomasmo
Ciure Andrei