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
This patch ensures that we push clips in WR for each display item,
reflecting the display item's clip chain as computed in Gecko. A display
item will often share part or most of its clip chain with other display
items, so we try to reuse the corresponding WR clip ids as much as we
can instead of defining new duplicated clips.
MozReview-Commit-ID: LkBh8LIpQ4J
--HG--
extra : rebase_source : 5af1de0931f1d059e98b5c66b15988961503e114
This regenerates the cargo lockfiles and FFI bindings header. It also revendors
the third_party/rust libraries.
MozReview-Commit-ID: ID0YhoIH6cz
--HG--
extra : rebase_source : 7c22828a831eafcf527f2c3baf8d4d012db8f9a4
Previously, the WebRenderBridgeParent for each content layer tree would use the
same WebRenderAPI instance as the top-level WebRenderBridgeParent for that window.
However, in order to make the namespacing changes work we now need to use a
separate WebRenderAPI instance for each WebRenderBridgeParent. The content
WebRenderAPIs are cloned from the parent one, so that they all share the same
backend, but can allocate resource IDs in distinct namespaces.
MozReview-Commit-ID: 7VTFL8F09n7
--HG--
extra : rebase_source : 2da1d03abc23bd7852e4b12fe133889bd80cad53
In theory the upstream API change should allow us to share the same WR renderer
instance across multiple WebRenderAPI instances. For now however I retain the
existing behaviour of one WR instance for each WebRenderAPI instance, but keep
track of the document id in a new DocumentHandle struct. The C++ side keeps
a pointer to this DocumentHandle struct instead of the raw RenderApi.
MozReview-Commit-ID: I9pCKOY1OYx
--HG--
extra : rebase_source : 7b0ae2ccb2692a76045371ac165468c7f7539b40