This patch include two performance improvements:
- Only rebuild the DC visual tree if different from last frame.
- Use EGLImage instead of pbuffer for DC <-> GL interop.
These fix most of the talos regressions with DC enabled in WR.
Differential Revision: https://phabricator.services.mozilla.com/D53916
--HG--
extra : moz-landing-system : lando
MigrateToActiveGPU is only called on compositor GLContexts, not for WebGL.
See bug 1597547 for WebGL.
After this fix, the situation can be improved in multiple ways:
- Rather than moving contexts between GPUs, it would be better to have separate
contexts for each GPU, and teach our compositors to switch a window over to
a new context.
- Instead of creating a fresh context to obtain the "preferred" GPU, we should
find the GPU that drives the display on which the context's results are going
to be displayed.
Differential Revision: https://phabricator.services.mozilla.com/D53719
--HG--
extra : moz-landing-system : lando
This setting was only respected for manually-created fake "default" framebuffers,
by code that no longer exists.
Differential Revision: https://phabricator.services.mozilla.com/D52922
--HG--
extra : moz-landing-system : lando
This depth buffer would only be created for the default framebuffer, but there is
no default framebuffer on macOS (since all rendering goes into IOSurfaces), so
this attribute is ignored.
We already manually create depth buffers for the IOSurface framebuffers.
Differential Revision: https://phabricator.services.mozilla.com/D52921
--HG--
extra : moz-landing-system : lando
This seems to be what other platforms do. FORCE_ENABLE_HARDWARE is controlled by the pref webgl.force-enabled.
gl.require-hardware was only read on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D52920
--HG--
extra : moz-landing-system : lando
This distinction is not meaningful with CoreAnimation because all rendering happens into IOSurfaces.
Differential Revision: https://phabricator.services.mozilla.com/D52919
--HG--
extra : moz-landing-system : lando
This code was trying to not render things upside down when rendering to offscreen contexts.
But this code path was never used and it wasn't fully working.
I would like to make our compositor contexts go through GLContextProviderCGL::CreateHeadless,
which creates an "offscreen" GLContext, so now this broken code is kicking in. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D52917
--HG--
extra : moz-landing-system : lando
We are no longer using a pinned version of serde, so update to avoid the
dependency on older syn / quote / etc.
Differential Revision: https://phabricator.services.mozilla.com/D53375
--HG--
extra : moz-landing-system : lando
There are three reasons for doing this.
1. It makes the NativeLayer API more compatible with DirectComposition.
2. Copying existing content may be faster than redrawing those pixels. Redrawing
might have some amount of overdraw which takes up more memory bandwidth.
3. Most importantly: Partial updates now have "unidirectional flow of information":
The renderer decides which area to redraw, and it redraws exactly that area.
In the past, partial updates required the following dance:
- Figure out what area changed in this frame. Call that area A.
- Invalidate that area in the NativeLayer.
- Get the next surface for drawing from the layer.
- Request the actual invalid area in the current surface. Call that area B.
- Redraw B.
Now with this change, the renderer no longer needs to care about B, and can just
redraw what changed in the current frame (A).
This is useful for WebRender because WebRender prepares drawing commands on a separate thread
before it executes them on the render thread. And at the time of preparation, WebRender does
not have access to the native layer. It needs to know what to draw ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D51760
--HG--
extra : moz-landing-system : lando
This gives us easy access to a surface that has valid content. In the next patch,
we will use this surface to copy valid content from.
Differential Revision: https://phabricator.services.mozilla.com/D51759
--HG--
extra : moz-landing-system : lando
This involves two new IPC messages (both async) to propagate the change in
compositor options (of which APZ enablement is one) from the GPU process to
the parent process (via PCompositorBridge) and on to the content process
(via PBrowser).
The support is only partial, in that going from non-APZ to APZ is only
supported if APZ was enabled at the time the window was created.
Depends on D51467
Differential Revision: https://phabricator.services.mozilla.com/D51468
--HG--
extra : moz-landing-system : lando
If only the APZ enablement changed, produce a warning rather than an assertion.
Differential Revision: https://phabricator.services.mozilla.com/D51467
--HG--
extra : moz-landing-system : lando
Use Vec::reserve + as_ptr, then raw pointers.
Alternative is to require T: Default, and then push T::default() or something.
Differential Revision: https://phabricator.services.mozilla.com/D53360
--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
This stops the potential build up of held textures during a series of empty
webrender transactions, because of a render not happening. The patch also only
sends the OpUpdatedAsyncImagePipeline command when a new texture has been
forwarded for the canvas, to prevent unnecessary invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D53223
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
We already snap the complex clip rects during scene building, taking
into account any necessary transforms and device pixel scaling. Just
like normal clips, we shouldn't round in layout space.
Differential Revision: https://phabricator.services.mozilla.com/D52673
--HG--
extra : moz-landing-system : lando
If the render backend is producing frames too quickly for the
renderer thread to consume, old frames are dropped in favor of
the most recent frame.
When this occurs, we need to ensure that any native surface updates
from the skipped frame are also applied. Otherwise, the state of
the native surfaces list can get out of sync between the renderer
and render backend threads.
Differential Revision: https://phabricator.services.mozilla.com/D53122
--HG--
extra : moz-landing-system : lando
On Windows, save the Ctrl-Shift-3 capture to the user's local app data
to make sure we have write permissions.
Verified with ./mach run + capture => saved to C:\Users\...\AppData\Local\wr-capture
Differential Revision: https://phabricator.services.mozilla.com/D53208
--HG--
extra : moz-landing-system : lando
In Draw compositor mode, tiles are placed into a bucket based on
the tile kind and/or opacity. This simplifies the renderer code
for this mode, which uses the z-buffer to reject opaque tiles.
In native compositor mode, the tiles need to be submitted in the
correct draw order. Opacity is a property of the native surface,
and should not affect the order the tiles are added to the visual
tree of the native compositor.
Differential Revision: https://phabricator.services.mozilla.com/D52933
--HG--
extra : moz-landing-system : lando
sotaro
Glenn Watson
Markus Stange
Jonathan Kew
Lee Salzman
Emilio Cobos Álvarez
Daniel Varga
Andrew Osmond
Botond Ballo
Matt Woodrow
Bob Owen
James Hooks
Brindusan Cristian
Doug Thayer
Bert Peers
Ting-Yu Lin
Dzmitry Malyshau
Sylvestre Ledru
Josh Matthews