`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
We used to do this before bug 1860328 (see also bug 1547802, which
introduced this wallpaper).
Keep doing it, but teach it to deal with multiple carets. I don't want
to keep chasing caret invalidation issues, and it's probably not worth
the time given we almost always paint 0 or 1 caret.
Differential Revision: https://phabricator.services.mozilla.com/D206257
In order to create less WebRenderLayerScrollData currently we use a deferred transform item
https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82
We don't need a WebRenderLayerScrollData for every transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.
However this optimization can lead to us creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.
WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.
This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.
I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.
Differential Revision: https://phabricator.services.mozilla.com/D197446
This testcase hits a rare condition where the abs pos frame is under the first continuation of the containing block frame, but the placeholder frame is under the next continuation of th containing block frame. This means that the walk in FindContainingBlocks which adds the ForceDescendIntoIfVisible bit to all ancestors of modified frames (walking through placeholders) never marks the first continuation of the containing block frame, which is the actual frame that contains the modified frame. That means that we don't walk into the containing block for the modified abs pos frame, and so we don't call MarkAbsoluteFramesForDisplayList, which computes the dirty rect for the abs pos frame, and if it is non-empty it would walk it's ancestor chain through placeholders and add the NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO bit. But we don't do that, so when we come to build the display list for the placeholder frame, the placeholder frame has size 0x0 of course, so we determine it is not visible, and even though the ForceDescendIntoIfVisible bit is set on it, since it's not visible we don't descend into it. We need the NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO bit which would have been set.
So for this to work we need to make sure in addition to the ancestor chain walking through placeholders has the ForceDescendIntoIfVisible bit set, we also need to make sure the normal GetParent ancestor chain has that bit set. So anywhere that we use GetDisplayListParent where this kind of fix seems like it is needed we need to modify. We try to be a bit clever to try to avoid any extra work for this rare case. We do this by checking if we are going to be jumping to the placeholder, and if so we make sure to mark the parent of the current frame, before continuing up the GetDisplayListParent walk. This doesn't visit anymore frames as in the common case we stop the walk when we get to the parent frame because the ForceDescendIntoIfVisible bit is set on it. This does add a function call overhead though.
When we hit this condition we do have to walk more frames. To make sure this condition isn't too common, and thus aren't making ourselves walk a lot more frames, I did a full try run on linux to see how often it was hit. We hit it 3 times. layout/base/crashtests/1464641.html which is a reduced testcase of another retained display list bug. testing/web-platform/tests/svg/layout/svg-with-precent-dimensions-relayout.html. And layout/reftests/display-list/1709452-1.html which is another retained display list bug, which also has to do with continuations and it is almost an identical copy of the reduced testcase of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D174458
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
