In all those cases, the current nsISerialEventTarget is either the main thread or the MessageChannel's nsISerialEventTarget (since bug 1634846)
Differential Revision: https://phabricator.services.mozilla.com/D81966
This moves the clipping responsibility into the layer. It also brings back
assertions that make sure that no invalid content reaches the screen.
On the layer side I'm renaming validRect to displayRect, because at the time
NextSurface* is called, that rect is not yet valid.
This implementation also allows having valid content outside of the display
rect. So, for example, if you grow and shrink the display rect multiple times
but most of the outer parts are transparent, in theory this allows you to paint
the transparent pixels only once rather than every time the display rect
expands.
Differential Revision: https://phabricator.services.mozilla.com/D79842
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
This is so that we can invalidate all layers when screenshot profiling has
started, and not just the first layer.
Differential Revision: https://phabricator.services.mozilla.com/D43874
--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
aClipRect is relative to
closestAncestorContainerLayerWithIntermediateSurface->GetVisibleRegion().GetBounds().TopLeft()
or (0, 0) if there is no ancestor with an intermediate surface.
It gets computed by Layer::CalculateScissorRect.
So if there is an intermediate surface, that origin matches the render target
origin. But if there is no intermediate surface, it does not always match: the
root render target's origin is not necessarily (0, 0).
In the past, BasicCompositor dealt with this by using the transform on the root
render target's mDrawTarget, which gets set in CreateRenderTargetAndClear
(renamed to CreateRootRenderTarget in this patch). Render targets created in the
regular CreateRenderTarget did not have a transform.
This allowed DrawGeometry to only conditionally apply an offset to aClipRect;
the offset was applied by calling PushClipRect before resetting the transform.
Now all render targets have a translation by -offset on their DrawTarget, not
just the root render target.
I went with an explicit "clip space origin" field on the render target.
Other alternatives would have been:
- Having a bool IsRootRenderTarget() and using that to conditionally offset
aClipRect by the render target origin or not.
- Changing Layer::CalculateScissorRect so that the clip space origin is always
(0, 0). I actually tried this first but ran into trouble with the MLGPU code.
We can do it later.
Differential Revision: https://phabricator.services.mozilla.com/D43866
--HG--
extra : moz-landing-system : lando
The old code was making an autoRestoreTransform around dest and then quickly
overwriting dest with something new. I prefer creating the autoRestoreTransform
for buffer, which doesn't change over the course of this function.
Differential Revision: https://phabricator.services.mozilla.com/D43384
--HG--
extra : moz-landing-system : lando
This removes one user of mDrawTarget.
This change only makes a difference when we have a backbuffer; now we will create
DrawTargets that are similar to the back buffer instead of the front buffer.
Differential Revision: https://phabricator.services.mozilla.com/D43381
--HG--
extra : moz-landing-system : lando
This makes it clear that only one of the possible call paths of
CreateRenderTargetForWindow can use a back buffer.
It causes some unfortunate duplication of the clear region computation.
Differential Revision: https://phabricator.services.mozilla.com/D43380
--HG--
extra : moz-landing-system : lando
This eliminates a boolean parameter whose meaning is not immediately obvious at the call site.
Depends on D43378
Differential Revision: https://phabricator.services.mozilla.com/D43379
--HG--
extra : moz-landing-system : lando
None of the three main if branches in TryToEndRemoteDrawing were entered in that case:
- if (!aForceToEnd && !mTarget && NeedsToDeferEndRemoteDrawing()) wasn't entered because
mTarget was non-null.
- if (mRenderTarget->mDrawTarget != mDrawTarget) wasn't entered because mTarget
drawing doesn't use a back buffer.
- if (aForceToEnd || !mTarget) wasn't entered because aForceToEnd was false and
mTarget was non-null.
Depends on D43377
Differential Revision: https://phabricator.services.mozilla.com/D43378
--HG--
extra : moz-landing-system : lando
It turns out there's not much benefit to creating the DrawTarget at the beginning of the frame.
It's only needed between NormalDrawingDone() and EndFrame().
Depends on D43376
Differential Revision: https://phabricator.services.mozilla.com/D43377
--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
There are three circumstances that make these transformations equivalent:
- aClipRectIn and aClipRectOut are never both non-null.
- The value of *aClipRectOut is ignored if *aRenderBoundsOut is empty.
- aRenderBounds.TopLeft() is always (0, 0) because the ClientLayerManager
calls targetBounds.MoveTo(0, 0) on the rect that eventually becomes
aRenderBounds.
(targetBounds -> Transaction::mTargetBounds -> TargetConfig::naturalBounds()
-> LayerManagerComposite::mRenderBounds)
Depends on D43367
Differential Revision: https://phabricator.services.mozilla.com/D43368
--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
