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
This change does the following:
* Introduce a new smart pointer called CounterStylePtr which either
holds an AnonymousCounterStyle strongly, or a named CounterStyle
managed by CounterStyleManager weakly, and use it to replace all
RefPtr<CounterStyle> around the codebase.
* Rename CounterStyleManager::mCacheTable to mStyles to reflect the
fact that it is used to manage all styles, not just for caching.
* Add a retired styles list which collect all named CounterStyle
evicted from mStyles, and post a PostRefreshObserver to destroy
objects in that list after next flush.
* Remove helper functions for counter style in nsStyleList and expose
mCounterStyle directly, to make code simpler with the new pointer.
Reason for adding a new smart pointer type rather than making their
AddRef/Release behave like BuiltinCounterStyle is that, it is possible
that after a flush, some stale style structs may still be alive. They
can contain pointer to destroyed CounterStyle objects. Although the
actual content may never be accessed anymore, RefPtr may still access
the object for refcounting during destruction.
MozReview-Commit-ID: xxegwSDhNb
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This uses the StackingContextHelper and typed helper functions in
WebRenderLayer to simplify WebRenderTextLayer::RenderLayer. It also
removes the implicit assumption in WebRenderTextLayer that the parent
layer pushed a stacking context, which is an assumption we will
probably break in the future.
MozReview-Commit-ID: CARoGVQd56i
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This is a largely uninteresting patch that just uses the DisplayListBuilder
directly. A wonderful cleanup patch will come after this. One of the more
interesting pieces is the use of PushBuiltDisplayList. This is needed for
handling empty transactions. See https://github.com/servo/webrender/pull/934
for more info.
This basically just splits the enum in two and does the necessary plumbing. The
worst part is that now DisplayItemLayers need to have two arrays of commands.
Fortunately, this will be going away in the future.
This makes it so we don't send the child side commands to the parent.
This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
