This makes the DisplayListBuilder scrolling API more consistent with the
clipping API, and allows for more optimization at the call site (in the next
patch).
MozReview-Commit-ID: LdCA7wkXDwF
--HG--
extra : rebase_source : 1fe934e778c597f6a639ad2ecbda46995f8fd09e
This also splits the wr_dp_push_scroll_layer function in bindings.rs into two
separate functions. This makes the API consistent with clipping, and also allows
for optimizations in the upcoming patches.
MozReview-Commit-ID: IXnOZK0dZm
--HG--
extra : rebase_source : aa28875433a03ee9d6c388750f022958958d05e9
A RasterImage's ImageContainer is only retained as a weak pointer in the
RasterImage itself. With WebRender and display items, we no longer kept
a strong reference to said image container, and as such it got recreated
every time it had to repaint (e.g. after a scroll). This would
unnecessarily reset/update the generation counter such that the
ImageClient would decide it needs to retransmit the image data to the
GPU process. By keeping a strong reference to the container that we
don't otherwise use, we avoid this situation.
WebRenderBridgeParent holds uninitialized mPipelineId when it was created by WebRenderBridgeParent::CreateDestroyed(). Then when CrossProcessCompositorBridgeParent::DeallocPWebRenderBridgeParent is called for the WebRenderBridgeParent, it will call EraseLayerState with some garbage uninitialized value, and so it will erase some random layer state entry.
To render the nested transforms properly, we need to store the inherited scale from ancestors for children.
Then apply the inherited scale for children's bounds
MozReview-Commit-ID: KYyibUD8J2j
--HG--
extra : rebase_source : 82c2695990e23eb47a4f185e0a53a865f3d1ff0f
To render the nested transforms properly, we need to store the inherited scale from ancestors for children.
Then apply the inherited scale for children's bounds
MozReview-Commit-ID: KYyibUD8J2j
--HG--
extra : rebase_source : fe2aeb842af477475767d0cf22c780c36b2487f0
This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget
hack. The old design had several limitations:
* It couldn't handle shadows
* It couldn't handle selections
* It couldn't handle font/color changes in a single text-run
* It couldn't handle decorations (underline, overline, line-through)
Mostly this was a consequence of the fact that it only modified the start and end
of the rendering algorithm, and therefore couldn't distinguish draw calls for different
parts of the text.
This new design is based on a similar principle as DrawTargetCapture, but also passes
down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can
notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us
directly pass data to TextDrawTarget when possible (as is done for shadows and selections).
In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle
changes in font/color mid-text-run (which can happen because of font fallback).
The end result is:
* We handle all shadows natively
* We handle all selections natively
* We handle all decorations natively
* We handle font/color changes in a single text-run
* Although we still hackily intercept draw calls
* But we don't need to buffer commands, reducing total memcopies
In addition, this change integrates webrender's PushTextShadow and PushLine APIs,
which were designed for this use case. This is only done in the layerless path;
WebrenderTextLayer continues to be semantically limited, as we aren't actively
maintaining non-layers-free webrender anymore.
This also doesn't modify TextLayers, to minimize churn. In theory they can be
augmented to support the richer semantics that TextDrawTarget has, but there's
little motivation since the API is largely unused with this change.
MozReview-Commit-ID: 4IjTsSW335h
--HG--
extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
This patch takes the existing code (which allows recursively pushing the necessary
part of a clip chain) and folds it into another recursive function that
operates on the ASR chain. Now the ASR recursion is the primary one, and
clips are pushed for each ASR as needed.
This code was partly modelled after the code in
ContainerState::SetupScrollingMetadata, which also iterates over the
ASRs and clips.
MozReview-Commit-ID: 1qaFPY7Ja7
--HG--
extra : rebase_source : 623b116c293e86d063e5acfa4a01f5104719f560
This allows us to keep a single stack where we track both clip ids and
scroll ids with the correct interleaving order that they were pushed in.
MozReview-Commit-ID: DHHfR8JnnBw
--HG--
extra : rebase_source : f2f80e89a400d5b9982d138b29e534701b247072
This patch takes the existing code (which allows recursively pushing the necessary
part of a clip chain) and folds it into another recursive function that
operates on the ASR chain. Now the ASR recursion is the primary one, and
clips are pushed for each ASR as needed.
This code was partly modelled after the code in
ContainerState::SetupScrollingMetadata, which also iterates over the
ASRs and clips.
MozReview-Commit-ID: 1qaFPY7Ja7
--HG--
extra : rebase_source : 0c1879531e77998254d2ccaf87479154b179545a
This allows us to keep a single stack where we track both clip ids and
scroll ids with the correct interleaving order that they were pushed in.
MozReview-Commit-ID: DHHfR8JnnBw
--HG--
extra : rebase_source : 1eff7698ecc724b5457bdf67a6c4a70605038184
A basic sanity check here seems to produce the correct behaviour but I'm
not at all confident that this will always do the correct thing in more
complex cases or when perspectives are involved. However this is hard to
test and get working without the testing infrastructure up and running
so I'd rather land this simple code first and then dig into the more
complex cases once we have a way to catch regressions.
MozReview-Commit-ID: E4HytiZowEn
--HG--
extra : rebase_source : c7466092298aebf66926e8e0bdf58eb4651f0f19
Nicolas Silva
Wes Kocher
Kartikaya Gupta
vincentliu
Lee Salzman
Andrew Osmond
Sebastian Hengst
sotaro
Jeff Muizelaar
peter chang
Ethan Lin
Alexis Beingessner