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
Recording mask clips in the clip stack changes the value of TopmostClipId()
which confuses the code in ScrollingLayersHelper. The mask clip can be
thought of as an "out-of-band" clip that ScrollingLayersHelper doesn't
need to know about. This patch adds a mechanism for pushing such
"out-of-band" clips without touching the clip stack.
MozReview-Commit-ID: 8Zeqtigk0cj
--HG--
extra : rebase_source : 35176f3c9d98d186f78d7a0ff44845c7c3c9f67e
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
Note that when PushClipAndScrollInfo is called, we are pushing an
already-defined scrolling clip onto the stack, and anything that gets
pushed inside it is going to be defined as being inside that scrolling
clip. So we need to make sure to update the scroll id stack for those
calls as well. This was an oversight previously but it never mattered.
MozReview-Commit-ID: D40Gk00HYrq
--HG--
extra : rebase_source : 677a92f918481a73877f551b9ac32975e0110be9
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
Note that when PushClipAndScrollInfo is called, we are pushing an
already-defined scrolling clip onto the stack, and anything that gets
pushed inside it is going to be defined as being inside that scrolling
clip. So we need to make sure to update the scroll id stack for those
calls as well. This was an oversight previously but it never mattered.
MozReview-Commit-ID: D40Gk00HYrq
--HG--
extra : rebase_source : beee11f8694489183dbeb4edcd95d89f55656486
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