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
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
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
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
The TransactionBuilder class comes with a bunch of baggage (it
automatically allocates/deallocates a transaction under the hood) which
we will want to avoid for the RB callbacks into APZ. This patch adds a
lightweight TransactionWrapper class that APZ can use to provide the
async transform info and that will be simpler to use in the callback
from rust code.
MozReview-Commit-ID: 1ywhx4TIzGd
--HG--
extra : rebase_source : 0ac4356554db24806d03b44f5384f9b7341d4255
Although they still happen in the same transaction, they are done in two
separate frame messages. This results in better encapsulated code on the
C++ side since we don't have to pass around an array of properties, and
will simplify future changes to update these properties at render time
rather than at GenerateFrame time.
MozReview-Commit-ID: 9qUkHX7gmD1
--HG--
extra : rebase_source : 15a319ba270eb1783815c514ae05c6a72e323dac
This was only recently made possible by webrender#2600, which introduced special stacking-context
clips
MozReview-Commit-ID: HQAU7IsfDaz
--HG--
extra : rebase_source : 0ac7f0f3f73abdf5b60ca02b37cfaa7abeecb6a3
This is all the (bidirectional) glue that connects the SceneBuilderHooks
to the APZUpdater.
MozReview-Commit-ID: JIqUaClVa57
--HG--
extra : rebase_source : c6da81e63793570f79cdfa153f6d33d2ac05bdf6
Until all the pieces are in place, turning on this pref will probably
break horribly. But we need the pref so we can add the rest of the
pieces without enabling them by default.
MozReview-Commit-ID: 7DkcwZgXwhx
--HG--
extra : rebase_source : e1fdef2e9a682028df524f51f767a4d2187410b1
This includes a signature change from CompositorBridgeParentBase ->
CompositorBridgeParent which is not strictly required, but it makes it less
likely that we'll accidentally create a WebRenderAPI from somewhere else
and pass a nonsense window id. In effect, the signature change makes it
likely that only CompositorBridgeParent will allocate the window ids.
MozReview-Commit-ID: 8AnnmI8RytR
--HG--
extra : rebase_source : 6fd957c4a9e5bb2175bee2cc89f7eb6d27a6bc9e
Instead of hard-cording the root scroll frame id, get the value from
WebRender. This was previously hard-coded to 0, so when WebRender
switched to using 1 for the root scroll frame id, the positioning of
sticky frames were broken in subtle ways. This happened because they
were being parented to a root reference frame (which now uses the 0 id)
instead of the root scroll frame.
MozReview-Commit-ID: 66ArgKHGpWE
--HG--
extra : rebase_source : ff6937bf7fc8d4472eb074d0466c8dcd6fba54a8
When comparing a Maybe<WrScrollId> to another WrScrollId we need to properly
handle the case where Nothing() signifies the root scroll frame. This is
equivalent to calling scrollId.valueOr(FrameMetrics::NULL_SCROLL_ID), as was
done before WrScrolLId replaced ViewId in the WebRender ScrollingLayersHelper.
We also have DisplayListBuilder::TopmostScrollId always return a value instead
of a Maybe, since an empty clip stack means that the current scroll id is that
of the root scroll frame.
Previously Nothing() was not equivalent to WrScrollId { 0 }, which caused the
ScrollingLayersHelper to fill the mClipAndScroll value and push another
set of clip and scroll nodes onto the WebRender display list builder.
MozReview-Commit-ID: CeatZlRXtuI
Kartikaya Gupta
Hiroyuki Ikezoe
Martin Robinson
Alexis Beingessner
sotaro
Noemi Erli
Lee Salzman
Andreea Pavel
Dzmitry Malyshau
Nicolas Silva
Brindusan Cristian
Ryan Hunt