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
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
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
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
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
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
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
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
With DXVA2 hardware-video-decoding, the RendererOGL should have a
synchronization mechanism to prevent the flickering of video texture.
Create a SyncObject in RendererOGL to do the texture synchronization.
The WebRenderAPI also exposes the RendererOGL's SyncHandle to
WebRenderBridgeParent. Then, the WebRenderBridgeParent could pass this SyncHandle
to the video decoding module for texture synchronization.
MozReview-Commit-ID: toQ2mO5fzG
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: AgMyNapY2Og
Previously we needed to pass by value and that was causing us to clear out our
prebuilt display list when we actually wanted to keep it around.
The rust code ended up doing a bit of a silly dance but that's better than copying the display list around.
In some cases we need to know the ancestor scrollid of a scrollid that we had
previously pushed onto the stack and then subsequently popped off. Since that
scrollid is no longer actually on the stack at the time of the query, we would
return Nothing(). Instead, this patch adds a map to "remember" previously
encountered scrollids and their ancestors, so that these queries can be correctly
handled.
MozReview-Commit-ID: BrtEv88ZysX
This patch is not really needed, but it avoids accidental conversion
between FrameMetrics::ViewID (which represents a scrolling clip) and a
uint64_t id for a non-scrolling clip.
MozReview-Commit-ID: JriIfpECHe7
This patch is not really needed, but it avoids accidental conversion
between FrameMetrics::ViewID (which represents a scrolling clip) and a
uint64_t id for a non-scrolling clip.
MozReview-Commit-ID: BU7p4WNocXa
Tracking the active clips and scroll layers is helpful for implementing
fixed-position type stuff, because we will need to answer questions like
"what is the ancestor scroll layer of this other scroll layer that is
somewhere on the stack" and "what is the currently active stack of
non-scrolling clips". This patch also adds a couple of methods to
WebRenderAPI that answers questions like these.
MozReview-Commit-ID: 9bgOW3Z8Tbp
In addition to updating webrender and webrender_traits, this patch:
- bumps the euclid dependency in webrender_bindings to match webrender
- updates the Cargo.lock files and re-vendors third-party rust packages
- updates the push_yuv_image callers due to an API change in WR cset a4b9e25.
