Put LayerManagerComposite in charge of creating and drawing to NativeLayers
Categories
(Core :: Graphics: Layers, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
References
Details
Attachments
(7 files, 8 obsolete files)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
At the moment (after bug 1491442), the NativeLayer object for the window is created and placed by nsChildView. On every composite, nsChildView hijacks the GL context's default framebuffer to trick CompositorOGL into drawing into the layer.
In this bug, I'm going to change things around so that nsChildView does not create a NativeLayer. Instead, the layer will be created and placed by LayerManagerComposite. And then CompositorOGL will know that it renders into a NativeLayer and it will create a CompositingRenderTargetOGL for the layer.
We need this because we want to composite separate parts of the window into separate framebuffers. The easiest way to do that is to make LayerManagerComposite create multiple NativeLayers and invoke compositing separately for each NativeLayer object.
Assignee | ||
Comment 1•5 years ago
|
||
This will give the layer manager direct access to the native layers.
Assignee | ||
Comment 2•5 years ago
|
||
This lets LayerManagerComposite and RendererOGL set the correct opaque region
on the native layer.
Depends on D42400
Assignee | ||
Comment 3•5 years ago
|
||
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.
Depends on D42401
Assignee | ||
Comment 4•5 years ago
|
||
Depends on D42402
Assignee | ||
Comment 5•5 years ago
|
||
Depends on D42403
Assignee | ||
Comment 6•5 years ago
|
||
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.
Depends on D42404
Assignee | ||
Comment 7•5 years ago
|
||
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.
Depends on D42405
Assignee | ||
Comment 8•5 years ago
|
||
The goal is to have three methods: BeginRenderingToWindow,
BeginRenderingToTarget, and BeginRenderingToLayer. All three of them would have
a corresponding EndRenderingToXYZ method. They'd be called between BeginFrame
and EndFrame.
This is the first step.
Depends on D42406
Assignee | ||
Comment 9•5 years ago
|
||
This means that the compositors now never have a target and a native layer at
the same time. So on platforms with native layers, "target" rendering won't go
to the screen anymore.
Depends on D42407
Assignee | ||
Comment 10•5 years ago
|
||
All these transformations should be completely behavior-preserving under the
current call paths. aClipRectOut is always non-null if aClipRectIn is null and
vise-versa.
Depends on D42408
Assignee | ||
Comment 11•5 years ago
|
||
Depends on D42409
Assignee | ||
Comment 12•5 years ago
|
||
This removes the aNativeLayer argument from BeginRenderingToWindow.
This duplicates quite a bit of code. I intend to clean up that duplication in
the future. But for now I want to allow these paths to diverge. It'll be easier
to share code once we see how the pieces fall into place.
Depends on D42410
Assignee | ||
Comment 13•5 years ago
|
||
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 D42411
Assignee | ||
Comment 14•5 years ago
|
||
This makes it clear that the other callers of CreateRenderTargetForWindow
never use a back buffer. (They always passed in BufferMode::BUFFER_NONE.)
Depends on D42412
Assignee | ||
Comment 15•5 years ago
|
||
Depends on D42413
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 16•5 years ago
|
||
Comment 17•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/de0c56e1ffad
https://hg.mozilla.org/mozilla-central/rev/c6d52b09f158
https://hg.mozilla.org/mozilla-central/rev/a63deabe60b2
https://hg.mozilla.org/mozilla-central/rev/587f31c95710
https://hg.mozilla.org/mozilla-central/rev/2067452a1f90
https://hg.mozilla.org/mozilla-central/rev/31348057830b
https://hg.mozilla.org/mozilla-central/rev/717f127c6729
Description
•