When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
It's still only used on Android, but keeping it and all code that interacts
with it inside an #ifdef is too much trouble for a tiny amount of space
saving.
Differential Revision: https://phabricator.services.mozilla.com/D48369
--HG--
extra : moz-landing-system : lando
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
This layer structure can still occur in cases where we place the RCD-RSF
scroll metadata on the root layer as a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D47655
--HG--
extra : moz-landing-system : lando
With container scrolling, layers that are fixed wrt. the RCD-RSF are no
longer descendants of layers with RCD-RSF metadata. This allows us to remove
some code that handles this case in AsyncCompositionManager.
In particular, when ApplyAsyncContentTransformToTree() calls
AlignFixedAndStickyLayers():
- If we are currently processing a layer with RCD-RSF metadata,
AlignFixedAndStickyLayers() will not do anything (because there will be
no descendants fixed wrt. the RCD-RSF), so it doesn't matter what
transform we pass to AlignFixedAndStickyLayers().
- If we are processing a different layer, then Metrics().IsRootContent()
will be false, so GetCurrentAsyncTransformForFixedAdjustment()
simplifies to just GetCurrentAsyncTransform().
As a result, GetCurrentAsyncTransformForFixedAdjustment() (and its helper
GetCurrentAsyncViewportTransform()) can be removed, and its use replaced
with GetCurrentAsyncTransform().
Differential Revision: https://phabricator.services.mozilla.com/D45595
--HG--
extra : moz-landing-system : lando
With containerless scrolling, scrollbar layers and their target scrolled layers
will be in sibling subtrees.
Depends on D45596
Differential Revision: https://phabricator.services.mozilla.com/D45918
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
This creates and updates layers that draw the same things as RenderDebugOverlay().
The code is duplicated so that the overlay can be independent of the compositing
layer content drawing. All layers need to be drawn first, and the GPU stats from
that layer are shown in mGPUStatsLayer.
Depends on D44336
Differential Revision: https://phabricator.services.mozilla.com/D44337
--HG--
extra : moz-landing-system : lando
CompositingRenderTargetOGL objects are no longer reused between frames. They are
recreated each frame around a reused framebuffer. This lets us remove the
SetOrigin method again, because we specify the right render target origin on
creation.
Depends on D44328
Differential Revision: https://phabricator.services.mozilla.com/D44329
--HG--
extra : moz-landing-system : lando
The tile size is configurable with the prefs layers.compositing-tiles.width/height.
On macOS, whenever a CALayer is touched, the window server will recomposite the
entire layer to the screen. There is no API to mark parts of a layer as damaged.
So if we want the window server to only redraw a small part of the screen, we
need to only touch small layers. This patch achieves that using tiles; whenever
the compositor needs to redraw an area, all tiles that overlap this area will
be drawn to their layers and the window server will recomposite those layers.
On Intel GPUs, compositing in tiles should also help reduce GPU times if there
are multiple layers of overdraw: The overdraw will have better cache locality.
However, the magnitude of this effect is not known and requires further research.
Differential Revision: https://phabricator.services.mozilla.com/D43881
--HG--
extra : moz-landing-system : lando
This means that when something changes in an opaque layer, the window server
only needs to copy the opaque layer to the screen and can avoid recomputing any
window backgrounds for transparent parts of the window. This can save power,
especially when transparent parts of the window use the macOS vibrancy effect,
which requires the window server to compute a blur and to composite windows
behind our window.
Differential Revision: https://phabricator.services.mozilla.com/D43880
--HG--
extra : moz-landing-system : lando
This change breaks the draw-fps overlay when using native layers. I'll try to
fix that in a new bug soon.
The do { } while(0) loop looks a bit odd, but it'll get replaced with a proper
loop in bug 1574586.
Differential Revision: https://phabricator.services.mozilla.com/D43879
--HG--
extra : moz-landing-system : lando
This removes any *TargetContext methods from the Compositor interface and moves
mTarget tracking into the compositor implementations.
Differential Revision: https://phabricator.services.mozilla.com/D43872
--HG--
extra : moz-landing-system : lando
In the end we want to have BeginFrameForWindow, BeginFrameForTarget, and
BeginFrameForNativeLayers, the latter with multiple Begin/EndRenderingToNativeLayer
pairs nested inside.
This is the first step.
CompositorOGL and CompositorD3D11 keep their internal BeginFrame method but make
it private.
Differential Revision: https://phabricator.services.mozilla.com/D43871
--HG--
extra : moz-landing-system : lando
Whenever *aRenderBoundsOut was non-empty and aClipRectOut was non-null,
*aClipRectOut was set to the same value as *aRenderBoundsOut.
Depends on D43368
Differential Revision: https://phabricator.services.mozilla.com/D43369
--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
In the past, mFullWindowRenderTarget was updated in EndFrame, so the captured
screenshots (which were captured before EndFrame) were always one frame behind.
This affected both profiler screenshots and window recording screenshots.
This also fixes a bug with the destination offset in the call to
mFullWindowRenderTarget->mDrawTarget->CopySurface(): In the case where mTarget
was non-null, those calls would use mTargetBounds.TopLeft() as the destination
offset, which is very much unrelated to anything in mFullWindowRenderTarget.
Now the destination offset for mFullWindowRenderTarget is always zero -
mFullWindowRenderTarget->mDrawTarget's device space is the same as window space.
This patch also moves the creation of mFullWindowRenderTarget down to where we
have mRenderTarget->mDrawTarget, so that we can create a DrawTarget of a type
that can efficiently copy from mRenderTarget->mDrawTarget. I think this is
important on Windows where mRenderTarget->mDrawTarget will be the Cairo/pixman
re-wrapped DrawTarget and mDrawTarget is some kind of Windows/GDI DrawTarget.
Depends on D41612
Differential Revision: https://phabricator.services.mozilla.com/D41613
--HG--
extra : moz-landing-system : lando
We only use the result of this calculation for composites to the actual window
(and stash it for later if this composite is to an external target), so
mTargetBounds is always unrelated.
Differential Revision: https://phabricator.services.mozilla.com/D40871
--HG--
extra : moz-landing-system : lando
alwu
Botond Ballo
Gurzau Raul
Martin Stransky
Oana Pop Rus
Bob Owen
Gerald Squelart
Markus Stange
Eric Rahm
Coroiu Cristina
Mihai Alexandru Michis
Sylvestre Ledru