Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
This is to avoid confusion with `IsScrollContainerFrame()` introduced in Part 3.
A note to performance concern:
We've used `IsScrollContainerOrSubclass()` in bug 1873414 to avoid expensive
`nsIScrollableFrame* sf = do_QueryFrame()`. Per [1], casting from `nsIFrame*` to
`nsIScrollableFrame*` has no fast path.
Ideally, `ScrollContainerFrame* sf = do_QueryFrame()` should be fast, and we can
use it to implement `IsScrollContainerOrSubclass()` like
`IsImageFrameOrSubclass()`. However, in this patch, I intend to keep the
performance metrics unchanged.
Remove `GetAsScrollContainer()` since it's only used in `MOZ_ASSERT`, and I'm
planning to remove `nsIScrollableFrame` in bug 1896516.
[1] https://searchfox.org/mozilla-central/rev/dd6e430c1bc2db90d9b3b1dd7e5215b4edc4d51a/layout/generic/nsQueryFrame.h#117-121
Differential Revision: https://phabricator.services.mozilla.com/D210395
Leaf frames can contain anonymous content, for example text control frames, and we were activating them before and not activating them caused a perf regression in some tests, so restore that behaviour.
This illustrates that some of the performance improvement of using the leaf check came from not descending into some subtrees and changes the perf balance of the patch from bug 1872564. I re-did the measurements with this new constraint and now the IsScrollContainer check is faster, so I switched to using that.
Differential Revision: https://phabricator.services.mozilla.com/D197904
The return value of nsLayoutUtils::AsyncPanZoomEnabled only changes if we descend into a frame whose display root widget is different. But that is not possible, we do not descend into any frames that are in different widgets.
Differential Revision: https://phabricator.services.mozilla.com/D197237
The return value of nsLayoutUtils::AsyncPanZoomEnabled only changes if we descend into a frame whose display root widget is different. But that is not possible, we do not descend into any frames that are in different widgets.
Differential Revision: https://phabricator.services.mozilla.com/D197237
These are small but they do show up in sp3 profiles.
IsPaintingToWindow is always true, so just assert it.
HaveScrollableDisplayPort is a simple pointer check, whereas AsyncPanZoomEnabled needs to jump several pointers (and WantAsyncScroll is slower yet), so change the order.
HasNonMinimalNonZeroDisplayPort is not needed unless we are inside that if, so don't call it outside the if.
Differential Revision: https://phabricator.services.mozilla.com/D191599
mScale is the zoom at the time the displayport margins were set, but
the resulting ScreenMargin will be interpreted in the context of the
scale at which we're about to paint, which may be different.
Note that mMargins themselves are not affected by these two scales
being potentially different, since we want the magnitude of the
margins to the constant in Screen pixels (i.e. a constant fraction
of the viewport size).
Differential Revision: https://phabricator.services.mozilla.com/D173577
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
There is one thing to note in this patch that is a change: this patch changes the displayport that we log for test purposes from the critical display port to the display port.
This will only be different on android. If tests were checking this then they were broken because the critical display port has no significance. I did a quick survey of the tests I could find that used this. None of them seem like they really want the critical display port (given the new world where critical display port has no significance).
Depends on D127350
Differential Revision: https://phabricator.services.mozilla.com/D127351
The reason that GetDisplayPortForVisibilityTesting was using Drop was because there is a test that sets a 10x zoom and we ran image visibility without updating the displayport base rect (painting would update it), so the returned displayport was based on the much larger base rect. The patches goal was to avoid the assert we removed. Using a displayport that large in that situation for image visibility seems fine because it shouldn't make us decode any more images then were previously already visible.
Depends on D127731
Differential Revision: https://phabricator.services.mozilla.com/D127732
No longer necessary, and it only NS_ASSERTION'd if we failed anyway, and we weren't even checking on mac and android due to the tiling pref.
Differential Revision: https://phabricator.services.mozilla.com/D127731
This stuff is now a no-op because the RequestContentRepaint message has a
higher priority than vsync.
Depends on D127033
Differential Revision: https://phabricator.services.mozilla.com/D127593
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
GetHighResolutionDisplayPort would return the displayport without the multipler in all situations (pref on or off).
In DisplayPortUtils we are checking the displayport rect before/after setting new displayport margins to see if it changes to determine if we need to invalidate. Since the critical displayport isn't used for anything, the regular displayport is the correct thing to use here.
In nsGfxScrollFrame we are doing a similar thing, except checking that the displayport doesn't change after a scroll.
In nsDisplayListBuilder::OutOfFlowDisplayData::ComputeVisibleRectForFrame it's also the correct thing, as we want to include the same rect for fixed content as we do for non-fixed content. But this is an significant expansion of the dirty rect of fixed content and the code history has fixes related to drawing too much of fixed content and OOMing so a little more scrutiny is reasonable. However if there was a problem with OOM, since this is the same rect we use for non-fixed content we would have OOM problems with regular content, so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D127344
Ting-Yu Lin