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 makes profiler screenshots and frame recording work again, when native
layers are used. The copying is a bit unfortunate. Maybe we can combine this
copy with the first downscaling step in the future. Or for frame recording,
which doesn't use downscaling, we could readback the layers individually and
reassemble them in CPU memory. But both of those solutions are more complex
than this.
Differential Revision: https://phabricator.services.mozilla.com/D43877
--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
The call to TransformAndClipBounds already clips destRect to renderBounds.
However, if the resulting rect was empty, the Inflate call would make it
non-empty again. And now the decision whether we would cull would depend on the
rect's position: Sometimes TransformAndClipBounds would place the empty rect at
a position along an edge of renderBounds, and then the inflated-from-nothingness
2x2 rect would overlap renderBounds and we wouldn't cull.
Differential Revision: https://phabricator.services.mozilla.com/D43870
--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
This also fixes DrawTargetSkia::CanCreateSimilarDrawTarget because currently
if only one of the height or width is negative then it doesn't get caught.
Differential Revision: https://phabricator.services.mozilla.com/D43075
--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
This is a remnant from the previous implementation of masking. That
implementation was replaced in bug 1447880.
Differential Revision: https://phabricator.services.mozilla.com/D43763
--HG--
extra : moz-landing-system : lando
On platforms that don't use native layers for rendering, we usually want reftests
to see exactly what's going to end up in the window. It's conceivable that
rendering into offscreen framebuffers might miss bugs on those platforms (though
I'm not sure if we've seen any evidence of this).
But when we're rendering to native layers, we have non-default framebuffers either
way, so we might as well create our own framebuffer rather than asking a native
layer for one. We're not interested in getting this rendering to the screen, so
it's better to leave the native layer out of this.
Differential Revision: https://phabricator.services.mozilla.com/D42406
--HG--
extra : moz-landing-system : lando
This makes CompositorOGL always render into offscreen render targets.
CompositorOGL no longer expects the GLContext to have a default framebuffer.
This duplicates a bunch of code from GLContextCGL, but that code can be removed
from GLContextCGL once WebRender no longer needs it.
This also makes it so that we don't recreate render targets on every frame;
instead, we create one render target for every IOSurface in the native layer's
"swap chain" and cycle through those render targets. We only throw away the
render targets when the window is resized or closed.
Differential Revision: https://phabricator.services.mozilla.com/D42405
--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
It's a really minor perf improvement, but also a cleanup IMO.
Also be a bit more const-correct while at it.
Differential Revision: https://phabricator.services.mozilla.com/D42985
--HG--
extra : moz-landing-system : lando
We defer ParentCommands when they come in attached to a display list,
but we forgot to defer them when they're sent directly. This was
causing us to crash when we defer updates that register textures
and the content process then suddenly decides we need to delete the
textures and only tells us through RecvParentCommands. We have no
idea what the textures are yet, so we need to defer these commands
along with everything else so that it's processed in the intended order.
Differential Revision: https://phabricator.services.mozilla.com/D39739
--HG--
extra : moz-landing-system : lando
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
Previously, additional dependencies (such as opacity bindings and
transforms) were stored in a simple hash set, which meant they
could not be correlated with primitive bounding rects (and thus
could not be used to derive dirty rects of a tile).
Now, by scanning the primitive list which contains the bounding
rect, we can also find additional dependencies for that primitive.
This will be used in future to create exact dirty rects (for
debugging / regression testing) and allow us to generate a
dependency descriptor for a split or merged tile from an existing
descriptor.
This patch also fixes a case where opacity bindings could result
in unnecessary invalidations, by retaining the opacity bindings
state across display lists.
Differential Revision: https://phabricator.services.mozilla.com/D42473
--HG--
extra : moz-landing-system : lando
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
The null is unnecessary because mDrawTarget is already null-checked above:
If mTarget is non-null, then mDrawTarget = mTarget so mDrawTarget is non-null.
If mTarget is null, then we would enter a branch that had another null check
for mDrawTarget.
As for the assertion: When rendering to an external target (reftests),
LayerManagerComposite always sets the invalid region to the entire window, so it
should never be empty here.
Differential Revision: https://phabricator.services.mozilla.com/D41677
--HG--
extra : moz-landing-system : lando
There was an interesting "ExpandToEnclose(IntPoint(0, 0))" call in
CreateRenderTargetForWindow that snuck in some surprising behavior that this
change makes a bit more visible.
Differential Revision: https://phabricator.services.mozilla.com/D41676
--HG--
extra : moz-landing-system : lando
In the past, BeginFrame would clip mDrawTarget to the invalid region and then have
CreateRenderTargetForWindow clear a rectangle. So it was effectively clearing a
region, but only if BeginFrame's region clip happened to be set on the correct
DrawTarget. In the case where a back buffer was used, this was not the case:
The clip would be on mDrawTarget but the clear would happen on the back buffer
draw target. So we were clearing more than necessary.
Now we limit clearing to the invalid region even if a back buffer is used.
Differential Revision: https://phabricator.services.mozilla.com/D41675
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
We only want the bottom LayerMetricsWrapper / WebRenderScrollDataWrapper to
be treated as a ref layer, and only ref layers have event regions overrides.
Differential Revision: https://phabricator.services.mozilla.com/D42339
--HG--
extra : moz-landing-system : lando
This seems to make a big difference when running tests with WARP.
e.g. Assertion failure: frameInfo.mDocFramesSeen == frameInfo.mDocFramesTotal,
at z:/build/build/src/gfx/webrender_bindings/RenderThread.cpp:303
and various other browser chrome test failures.
The original problem that added this flag only impacted AMD hardware as I
recall and we are unlikely to ever be running on WARP in production anyways.
When WARP is forced we also don't disable INTERNAL_THREADING_OPTIMIZATIONS.
Differential Revision: https://phabricator.services.mozilla.com/D42214
--HG--
extra : moz-landing-system : lando
There's no other caller that sets ReadBuffer to anything else, and GL_BACK is
the default for default framebuffers. Furthermore, this call triggers
GL_INVALID_OPERATION errors when called on a non-default framebuffer.
Differential Revision: https://phabricator.services.mozilla.com/D40551
--HG--
extra : moz-landing-system : lando
NativeLayerRoot and NativeLayer allow building up a flat layer "tree" of sibling
layers. They're created and manipulated with a synchronous-looking API, but any
changes will only be applied to the underlying native layers when ApplyChanges()
is called. This ensures that the modifications can be limited to run within a
CoreAnimation transaction, and on a thread of the caller's choosing.
In the near future I'm planning to have LayerManagerComposite create these
layers. That's the reason for the pseudo-abstracted cross-platform C++ API:
LayerManagerComposite can create and place the layers, and any painting into the
layer surfaces will happen in the compositor implementations with platform-specific
code.
For now, the CoreAnimation implementation is the only implementation. I think
the current API will let us use the same infrastructure for DirectComposite
layers on Windows, but we'll likely need to make some API modifications once we
attempt that.
The classes are threadsafe; their methods can be called on any thread and the
caller is responsible for sufficient synchronization. In reality, there are only
two threads that would have a reason to use these layers: The compositor thread
and the main thread. The main thread creates and destroys the NativeLayerRootCA,
and sometimes it calls ApplyChanges, e.g. during window resizes. It also calls
SetBackingScale. All other methods are usually only called on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D26407
--HG--
extra : moz-landing-system : lando
This removes the assumption that there is a default framebuffer to read from,
in order to prepare for a world in which all rendering goes into non-default
framebuffers.
The current render target's framebuffer is already bound when this function is
called.
Differential Revision: https://phabricator.services.mozilla.com/D40513
--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
These areas only need to be cleared in rt->mDrawTarget. Once the invalid area gets
copied over to mFullWindowRenderTarget, any cleared pixels will be copied over and
clear those pixels in mFullWindowRenderTarget.
This clear wasn't only necessary, it also sometimes cleared to much, because the
clip to the invalid region that the caller sets does not apply to this DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D41612
--HG--
extra : moz-landing-system : lando
The commit also adds a missing StaticPrefs_dom.h include for APZEventState.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D41915
--HG--
extra : moz-landing-system : lando
Since the filtered-backdrop is 1:1 with the backdrop, we don't want any snap offsets to shift the contents
Differential Revision: https://phabricator.services.mozilla.com/D42042
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
These were used for creating accelerated CGContexts that render to an IOSurface.
We only used those experimentally on Nightly for a while but turned that option
off because of crashes. And in the meantime, DrawTargetCG has been removed
entirely. So we'll probably never use these functions again.
Differential Revision: https://phabricator.services.mozilla.com/D41809
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
As a result of the expansion, position:fixed elements are attached to the
expanded layout viewport.
The expanded value is used behind a pref which is enabled by default on nightly
initially, and the pref will be fliped in bug 1571599 on other channels.
scrollbars-in-landscape-content.html still fails since the vertical overlay
scrollbar doesn't appear since we are not yet using the expanded value during
reflow to tell whether we need overlay scrollbars or not. This will be fixed
by the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D40771
--HG--
extra : moz-landing-system : lando
Fixes an issue when backdrop-filter is used many time on a page where we would
spend a large amount of time reevaluating render tasks when assigning task depths.
Differential Revision: https://phabricator.services.mozilla.com/D41252
--HG--
extra : moz-landing-system : lando
The user pref already takes precedent over the environment so there's no need
to run the code later. Further, we assert that environment values haven't been
set.
Differential Revision: https://phabricator.services.mozilla.com/D41836
--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
This makes us use the actual adapter description instead of a null one.
This fixes the problem of a mismatch being detected in ContentAdapterIsParentAdapter which
is using D3D11Checks::GetDxgiDesc to determine the adapter.
Differential Revision: https://phabricator.services.mozilla.com/D41804
--HG--
extra : moz-landing-system : lando