We push a bit up the tree during preroll to learn whether there system
composited layers below each layer. During update scene, we squash down
to paint tasks, which we execute after publishing the new scene.
When we pipelined the drawing commands we caused UpdateScene to be called
before Preroll, which isn't allowed. Now we call Preroll, UpdateScene, and
Paint separately.
We could get into a situation where the second time we rasterize a picture for an SKP, the raster cache detects that the same picture is being repeated in subsequent onscreen frames and then proceeds to rasterize the contents to an offscreen texture. This not only causes an unnecessary cache entry, but also shows the cached image in the final SKP trace (which is not what was originally displayed on screen).
This patch introduces a //glue library that isolates our dependency on //base.
This will let us clean up our //base dependencies ahead of actually being able
to fully remove them.
The code that draws the picture knows more about the picture (and the future)
than we do. This patch gives them a way to hint us about what's going to
happen with the picture in the future.
Instead, make Layer::Paint take a new PaintContext that has just exactly
the state that it needs, mirroring PrerollContext. Also, rename
PaintContext to CompositorContext because it holds the context for the
whole compositor.
Previously we were applying opacity in a different way than Skia
expects. Now we use the exact pattern that Skia expects so that we hit
more optimizations inside SkRecordOptimize.
After this patch, we don't actually get the optimization because we
don't yet run SkRecordOptimize over the composited tree. A later patch
will actually cause us to run SkRecordOptimize.
- fix dartdocs for addPerformanceOverlay
- make PerformanceOverlayLayer honour its x, y, and height.
- fix the y axis of PerformanceOverlayLayer to only show 3x16ms, since
if it's more than 16ms it really doesn't matter what it is.
- make the label on the PerformanceOverlayLayer show the worst time on
record not the instantaneous time.
- pin the fps to a maximum of 60Hz
When linking in a scene, it's a good idea to specify its clip rectangle
to ensure that its content does not draw or capture input from its
surrounding space.
A future version of the Mozart view manager may automatically wrap a
view's scene with a clip rectangle to avoid composition gotchas like this
but it currently doesn't. So the net effect is that if you embed a view
without specifying a clip, it can draw or capture input from anywhere
within its container.
Previously we just dropped child scenes on the floor. Now we upload them
to Mozart. However, we just draw them on top of all the other content
and don't apply any clips or blends.
