This largely reverts D81868, only keeping what's needed to make SwapBuffersWithDamage
work, and also adds BufferAge support to RenderCompositorOGL.
Differential Revision: https://phabricator.services.mozilla.com/D85565
RenderCompositorOGL currently has many responsibilities including supporting
OpenGL compositor for Linux, whole-window compositing for Mac NativeLayerCA,
and per-cache-tile compositing for Mac NativeLayerCA. With the addition of
support for SWGL, this becomes even further complicated.
It becomes advantageous to separate out RenderCompositorOGL specifically as
only the basic OpenGL compositing case, as that naturally yields a simple and
isolated RenderCompositor.
What is left over becomes RenderCompositorNative, a basis for implementing
NativeLayer-based RenderCompositors. To cleanly isolate state and details of
when HW compositing or SW compositing is being used, these are further split
off into RCNativeOGL and RCNativeSWGL versions that deal with specific
isolated details of OpenGL and SWGL respectively.
RCNativeOGL deals with just setting up OpenGL FBOs for NativeLayers.
RCNativeSWGL's new task is just to deal mapping NativeLayers and providing
SWGL FBOs for them without involving OpenGL.
Differential Revision: https://phabricator.services.mozilla.com/D80270
RenderCompositors for SWGL that wish to provide accelerated compositing need to
subvert the existing Bind/Unbind hooks in the WR compositor. These compositors
need to keep track of their HW tiles without actually binding an OpenGL FBO
for WR to render picture cache tiles. SWGL needs to intervene and get a backing
buffer for tile from the RenderCompositor so that it can create a SWGL FBO for
WR to render the picture cache tile to.
To that end, this adds MapTile/UnmapTile as a replacement for Bind/Unbind for
those scenarios. This is done in a way that it affects only the WrCompositor of
webrender_bindings without actually altering WR's Compositor interface. This is
beneficial because WR does not have to understand the details of SWGL
integration and also so as not to complicate other users of WR such as Servo
who are not currently utilizing SWGL at all.
RenderCompositorOGL is initially modified to use these hooks in this patch. It
later became more convenient to restructure that in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D80269
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
Bug 1632096 added the capability to shared gl context with WebRender. This bug extends the support to non shared gl context.
Differential Revision: https://phabricator.services.mozilla.com/D72579
This adds support for tracking and invalidating tiles based on a
movable virtual offset.
Differential Revision: https://phabricator.services.mozilla.com/D65687
--HG--
extra : moz-landing-system : lando
Use ThinVec instead, which is compatible with nsTArray, and makes stuff much
harder to misuse.
Differential Revision: https://phabricator.services.mozilla.com/D63256
--HG--
extra : moz-landing-system : lando
For Draw (non-native) and CA modes, we include the per-tile
valid rect in the clip rect from the surface.
For DC (non-virtual) mode, a per-tile clip rect is set on the
visual for each tile, separate from the overall clip rect that
is set on the surface visual.
For DC (virtual) mode, the Trim API is used to remove pixels
in the virtual tile area that are outside the valid / clipped
region.
Note: Although the valid rect is now applied in the native
compositors, it's currently only based on the overall picture
cache bounding rect. Thus, with this patch there isn't any
noticeable performance improvement. Once this lands and is
working correctly, the follow up patch to calculate a smaller
valid region per-tile is a small amount of work.
Differential Revision: https://phabricator.services.mozilla.com/D61424
--HG--
extra : moz-landing-system : lando
This fixes RenderCompositorOGL::DestroySurface to update mTotalPixelCount as needed when there are still tiles in the surface that's getting removed.
I'm also adding a few asserts and performing some minor cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D58518
--HG--
extra : moz-landing-system : lando
This will allow use of the DirectComposition virtual surface API. If
it turns out that some pages recreate surfaces a lot due to opacity
changing, we can add some extra logic to avoid recreating surfaces
as often, and making use of per-tile opacity in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D57592
--HG--
extra : moz-landing-system : lando
This makes it more similar to how SwapBuffers was used.
This patch also makes us call glFlush directly when using native layers, rather than going through the misleadingly-named GLContext::SwapBuffers method.
Differential Revision: https://phabricator.services.mozilla.com/D57062
--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
about:support could have an information that WR compositor is disabled by disabling picture caching.
Differential Revision: https://phabricator.services.mozilla.com/D57266
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
This replaces mUpdatesCount in AsyncImagePipelineManager, which was really how
many times NotifyPipelinesUpdated was called with aRender == true. I think this
makes the release logic clearer as it is more explicit.
It also changes things for RenderCompositorANGLE, so that we check to see if
any other frames have completed even if we don't want to wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D51064
--HG--
extra : moz-landing-system : lando
This implementation is off by default (behind gfx.webrender.compositor) until
various bugs and inefficiencies are fixed. See bug 1592016.
Differential Revision: https://phabricator.services.mozilla.com/D50726
--HG--
extra : moz-landing-system : lando
This implementation is off by default (behind gfx.webrender.compositor) until
various bugs and inefficiencies are fixed. See bug 1592016.
Differential Revision: https://phabricator.services.mozilla.com/D50726
--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
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26412
--HG--
extra : moz-landing-system : lando
On android, we want to use only RenderCompositorEGL for using sharedGL. Further RenderCompositorOGL does not work well with android SurfaceTexture.
Differential Revision: https://phabricator.services.mozilla.com/D25201
--HG--
extra : moz-landing-system : lando
On Wayland with WebRender, RenderCompositorEGL creates headless context by using GLContextProviderEGL::CreateForCompositorWidget(), since GetNativeData(NS_NATIVE_EGL_WINDOW) returns nullptr. But we want to make hadless explicitly. But GLContextProviderEGL::CreateHeadless() and GLContextEGL::CreateEGLPBufferOffscreenContext() could not be used for it. They creates incompatible EGLConfig to egl window. Then we extends GLContextProviderEAGL::CreateForCompositorWidget() to handle this case. When CreateForCompositorWidget() receives null widget, it creates GLContext without surface of egl window.
Differential Revision: https://phabricator.services.mozilla.com/D22454
--HG--
extra : moz-landing-system : lando
sotaro
Robert Mader
Nicolas Silva
Narcis Beleuzu
Lee Salzman
Markus Stange
Glenn Watson
Emilio Cobos Álvarez
Markus Stange
Glenn Watson
Cosmin Sabou
Bob Owen
Bogdan Tara
Nicholas Nethercote
Ryan Hunt