This class is a RAII class that can be used to push a stacking context
with properties from a WebRenderLayer. It can also then be used to
convert rects in the layer coordinate system to be relative to the
stacking context, which is what we want for passing to WR.
MozReview-Commit-ID: 1WVrfRYqLqc
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This removes the call to push_scroll_layer in wr_push_stacking_context, so that
it's now possible to push a stacking context without necessarily pushing a
scroll layer. There is already a separate function to push a scroll layer so the
call sites can do that. This patch just changes all the call sites that were
pushing a stacking context to also push a scroll layer, so there should be no
functional change. Future patches can remove the spurious scroll layers.
MozReview-Commit-ID: FtCkc9JQd8l
This introduces two new statistics to the overlay. The first is the ratio of
pixel shader invocations (as determined by the GPU) to the number of pixels we
determined need to be redrawn. The ideal ratio is 1.0, indicating that we
filled every pixel exactly once. Anything over 1.0 indicates overdraw.
We also add the ratio of shaded pixels to window size. This indicates how well
we computed the invalid region, and whether or not we overfilled that
region.
Note that the OpenGL and Basic compositors do not yet query the GPU for
this statistic, so they will estimate shader invocations by the area of
DrawQuad calls.
Finally, we remove the feature where layout can request the most
recent overdraw statistic. It was not implemented on all compositors, and the
only test that used it was disabled.
This is a largely uninteresting patch that just uses the DisplayListBuilder
directly. A wonderful cleanup patch will come after this. One of the more
interesting pieces is the use of PushBuiltDisplayList. This is needed for
handling empty transactions. See https://github.com/servo/webrender/pull/934
for more info.
This basically just splits the enum in two and does the necessary plumbing. The
worst part is that now DisplayItemLayers need to have two arrays of commands.
Fortunately, this will be going away in the future.
This makes it so we don't send the child side commands to the parent.
This simplifies the logic around displaylist builders and
makes us push immediately instead of deferring it. The data
we used to pass to pop() is now passed to push().
This is also closer to what Servo does.
In a follow up I'll rename some of the methods to closer
align with the webrender names.
MozReview-Commit-ID: AfkwT7DzJ8o
This simplifies the logic around displaylist builders and
makes us push immediately instead of deferring it. The data
we used to pass to pop() is now passed to push().
This is also closer to what Servo does.
In a follow up I'll rename some of the methods to closer
align with the webrender names.
The overall architecture here is that we add a new layers type, LAYERS_WR,
which can be used in place of client layers. The WebRenderLayerManager, in
the EndTransaction call, paints content into images and ships them over the
PWebRenderBridge to the compositor thread. The WebRenderBridgeParent code on
the compositor side talks to WebRender via the API in webrender.h.
MozReview-Commit-ID: JKLTLJWVXiN
