We currently don't ever set non-rectilinear transforms on our CALayers, so there
is no need for anti-aliasing. Explicitly disabling edge anti-aliasing means that
there are no seams between tiles when the window server draws our window with a
transform, such as during Mission Control.
Differential Revision: https://phabricator.services.mozilla.com/D103740
Some callers of NextSurface can tolerate a false return value. This moves the
release assert one level lower (more specific) towards
RenderCompositorNativeOGL::Bind, which can't handle a missing surface.
Differential Revision: https://phabricator.services.mozilla.com/D102344
This change spreads the release asserts to functions that are invoked by other
callers, potentially increasing the cases where the assert will fail. This is
being done intentionally; we want additional information on the reasons for
the crashes.
Differential Revision: https://phabricator.services.mozilla.com/D101063
This interface is never used directly, and the only consumers of the virtual functions are by the derived classes themselves.
Differential Revision: https://phabricator.services.mozilla.com/D93180
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Differential Revision: https://phabricator.services.mozilla.com/D89864
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Depends on D89863
Differential Revision: https://phabricator.services.mozilla.com/D89864
mOpaquenessTintLayer is a sibling layer of mContentCALayer, so the two layers
need the same transform and bounds.
This patch also removes an unnecessary twiddling of the position property.
Differential Revision: https://phabricator.services.mozilla.com/D86610
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
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
addUpdateRect needs to be called after beginFrame, otherwise it doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D59155
--HG--
extra : moz-landing-system : lando
The CARenderer documentation does not provide any guidance on how to use CARenderer with different resolutions.
In the initial implementation I simply tried the following: Make a device-pixel sized framebuffer, call glViewport with the device pixel size, and then call glOrtho with the "point" size. And this seemed to work.
However, it doesn't always work. When hooking up profiler screenshots, I noticed that in some cases, some layers would just not be rendered. Sometimes I even saw layers show up in wrong places.
After this patch, these problems no longer appear.
Differential Revision: https://phabricator.services.mozilla.com/D59154
--HG--
extra : moz-landing-system : lando
Suggestions for a better name than "snapshotter" are welcome.
This is a separate object so that the lifetime of its GLContext isn't governed by the lifetime of the NativeLayerRootCA.
The NativeLayerRootCA gets destroyed on the main thread, but GLContext uses non-threadsafe weak pointer support, so it wants to be destroyed on the same thread that it was created on.
So now the GLContext lives on the snapshotter, which is created and destroyed on the renderer thread.
Differential Revision: https://phabricator.services.mozilla.com/D57068
--HG--
extra : moz-landing-system : lando
The onscreen representation is attached to the NSView.
The offscreen representation is free-floating but will be used in a CARenderer in an upcoming patch.
Each representation is only updated on demand.
Differential Revision: https://phabricator.services.mozilla.com/D57067
--HG--
extra : moz-landing-system : lando
This will allow us to have two representations per NativeLayerCA in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D57066
--HG--
extra : moz-landing-system : lando
When updating the layer at 60fps, the surface that we would be leaving behind
here would usually still be in use at the time this method was called.
But when some time has passed since the last update, usually all surfaces in
mSurfaces are no longer "in use" so we can "compress" the swap chain to be
double-buffered.
Differential Revision: https://phabricator.services.mozilla.com/D54860
--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
There are three reasons for doing this.
1. It makes the NativeLayer API more compatible with DirectComposition.
2. Copying existing content may be faster than redrawing those pixels. Redrawing
might have some amount of overdraw which takes up more memory bandwidth.
3. Most importantly: Partial updates now have "unidirectional flow of information":
The renderer decides which area to redraw, and it redraws exactly that area.
In the past, partial updates required the following dance:
- Figure out what area changed in this frame. Call that area A.
- Invalidate that area in the NativeLayer.
- Get the next surface for drawing from the layer.
- Request the actual invalid area in the current surface. Call that area B.
- Redraw B.
Now with this change, the renderer no longer needs to care about B, and can just
redraw what changed in the current frame (A).
This is useful for WebRender because WebRender prepares drawing commands on a separate thread
before it executes them on the render thread. And at the time of preparation, WebRender does
not have access to the native layer. It needs to know what to draw ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D51760
--HG--
extra : moz-landing-system : lando
This gives us easy access to a surface that has valid content. In the next patch,
we will use this surface to copy valid content from.
Differential Revision: https://phabricator.services.mozilla.com/D51759
--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 allows us to somewhat cheaply swap out the entire set of layers.
It also means that clearing the array of layers no longer has quadratic complexity;
in the past, you would do this by calling RemoveLayer once per layer, and RemoveLayer
does a linear scan through the array.
Differential Revision: https://phabricator.services.mozilla.com/D50725
--HG--
extra : moz-landing-system : lando
