Instead of notifying the AsyncImagePipelineManager on the compositor
thread via the CompositorBridgeParent, we can send it the new pipeline
info directly from the RenderThread after the update happens. This
effectively splits the AsyncImagePipelineManager update-processing into
two parts: one that takes in the new pipeline info and one that process
it. This allows us to invoke the processing step from other code running
on the compositor thread, which we will need to do in the next patch.
MozReview-Commit-ID: 7xhm8I7bY4C
--HG--
extra : rebase_source : bfa62e326fd830bc2ef771138e5008fb2bc0d6b8
We do a silent upcast from CompositorBridgeParent* to the base class and
pass it around as a CompositorBridgeParentBase* for no reason. Avoiding
this simplifies the code slightly and avoids virtual function overhead.
We do need to move a couple of functions in CompositorBridgeParent from
protected scope to public scope.
MozReview-Commit-ID: 9Zq3GwxEXpr
--HG--
extra : rebase_source : 67346159e7d99ca7fc2fe0052e85aa6618b50d27
Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
We should always have the pipeline information for in-process things like
async images, but for cross-process iframes we might not have the information
right away if the content process doesn't get around to sending it for a while.
MozReview-Commit-ID: 18F5nqilXoV
--HG--
extra : rebase_source : 610046cbaaefb38b8e11bda857fd64a00722df27
This function is no longer used since we introduced TransactionWrapper class in
bug 1451469.
MozReview-Commit-ID: FGxi6thbxcP
--HG--
extra : rebase_source : ef5628f8bffb5c1fedf6de80056d4ebba41a9edf
This allows frames to be generated by the render backend thread even
while the scene builder thread is busy with a long scene build. The
GenerateFrame transaction also contains APZ and OMTA information, so
this allows the user to scroll and view OMTAnimations during long scene
builds.
MozReview-Commit-ID: KG5YC2KwIaH
--HG--
extra : rebase_source : 3ba559aa22a3a036a3b3a034ea20caacdc8c864a
This is just plumbing, no functional changes yet.
MozReview-Commit-ID: FlmnMVammse
--HG--
extra : rebase_source : edede45a77a829dbd125dc1f18a4c2a4bc8087c1
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
This is a refactoring that moves the "parent clip id" determination from
bindings.rs into WebRenderAPI.cpp. This should be functionally
identical.
MozReview-Commit-ID: 36rQmsH5E7J
--HG--
extra : rebase_source : f376e71f7681ec3f67e0ab4f2e3035da4edf2a5b
This ensures the commands to delete compositables are received by WR in the same
transaction as the updates to the display list that removes the references to
those compositables. Otherwise, WR can try to do a scene build on the intermediate
state which results in missing pipeline errors.
MozReview-Commit-ID: ByOHCFWSSjt
--HG--
extra : rebase_source : bcc0f129cbd75e3e9e3543236591b22687d39090
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 247e5b197e998682cb4bb74f6f9319a9a4dd3264
This also rearranges the method implementation slightly to make the next
patch easier to read. This patch should have zero functional changes,
it's just refactoring.
MozReview-Commit-ID: 53StJ0TH3IT
--HG--
extra : rebase_source : 2f3aeb54271da75a7e051afc24b8a4c96f8496f2
This prevents us from getting stuck in the frame throttling code where
TooManyPendingFrames always returns true.
MozReview-Commit-ID: 92tybPOaOTP
--HG--
extra : rebase_source : 8934f89a191759e85578db3dfde9e017a03a82eb
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 978e51dbedeb1542e0829752b7f828ffeb2872e9
sotaro
Kartikaya Gupta
Nicolas Silva
Hiroyuki Ikezoe
Martin Robinson
Alexis Beingessner
Ciure Andrei
Jonathan Kew
Cosmin Sabou
Andrew Osmond
Lee Salzman
Andreea Pavel
Noemi Erli
shindli