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
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125601
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
DisplayPortMargins objects are only meant to be created when setting
display port margins, not when querying them, because the object's
constructor records the visual and layout scroll offsets at the time
of construction to use for adjusting the margins to be layout-relative.
Differential Revision: https://phabricator.services.mozilla.com/D102075
This ensures that the notion of a scroll frame's scrollable ancestor used in
SetZeroMarginDisplayPortOnAsyncScrollableAncestor() to activate ancestors
when activating a scroll frame, matches what the actual ancestor is
according to display list building logic.
This avoids us taking the buggy "activate a scroll parent after the fact"
codepath (AutoCurrentActiveScrolledRootSetter::InsertScrollFrame()), which
can result in a display list with incorrect ASRs, in at least some cases.
Differential Revision: https://phabricator.services.mozilla.com/D100303
Timothy Nikkel
Butkovits Atila
Hiroyuki Ikezoe
Cristina Horotan
Botond Ballo
Dan Robertson
Emilio Cobos Álvarez
Marian-Vasile Laza
Miko Mynttinen
Alexandru Michis
Noemi Erli
Jeff Muizelaar
Sandor Molnar
Daniel Holbert
Matt Woodrow