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
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
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
I don't know why we keep using plain uint32_t and uint64_t values when
we have better types that we can use. This makes the code use and store
wr::Epoch natively instead of raw uint32_t values that are wrapped
on-demand.
MozReview-Commit-ID: HUVcHYSxBTi
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
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
