Closed Bug 1664626 Opened 4 years ago Closed 4 years ago

Rearrange code involving `visualScrollOffsetUpdated` in NotifyLayersUpdated

Categories

(Core :: Panning and Zooming, task)

task

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox82 --- fixed

People

(Reporter: kats, Assigned: kats)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

Spinoff from https://phabricator.services.mozilla.com/D88744#inline-510374 - there's some cleanup we can do to how we treat the visualScrollOffsetUpdated variable. This bug is mostly to address that review comment, and possibly do additional refactoring around Timothy's change around https://phabricator.services.mozilla.com/D89408#inline-509899

Quoting the first suggestion of Botond's review comment:

  1. Can we move the logic for setting visualScrollOffsetUpdated = false as a result of an instant eMainThread layout scroll into the ScrollPositionUpdate processing loop as well? (Instead of checking aLayerMetrics.GetScrollUpdateType() == FrameMetrics::eMainThread, we'd be checking something like scrollUpdate.GetMode() == ScrollMode::Instant && scrollUpdate.GetOrigin() != ScrollOrigin::Restore for every scroll update.)

This is fine, with one caveat: we need to check scrollUpdate.GetOrigin() for both ScrollOrigin::Restore and ScrollOrigin::None, because both of those are considered "low priority". Equivalently we can check using nsLayoutUtils::CanScrollOriginClobberApz since that also conceptually does the same thing (it is equivalent because APZ should never be getting a scroll update with NotSpecified or Apz origins, which are the other two origins checked for in that function).

I mention this because the patch I have up for review on bug 1664638 actually changes the above by getting rid of the ScrollOrigin::None scenario in all (or almost all) cases. So if that patch lands first, then checking for ScrollOrigin::Restore only would produce correct results, but I think would be less robust in case that patch gets removed later.

This should be equivalent but a little easier to reason about.

This introduces an ignoreVisualUpdate variable to make things a bit clearer.

Depends on D90721

The only remaining use site only cares about whether or not the transaction
was a paint-skip transaction or not, so this patch adds a dedicated bool for
that, which unlocks some cleanup.

Depends on D90722

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/56ef52f179cb
Move one of the conditions for ignoring a visual scroll update. r=botond
https://hg.mozilla.org/integration/autoland/rev/b4ee0000fe6a
Rearrange code for clarity. r=botond
https://hg.mozilla.org/integration/autoland/rev/2435b1b4a55d
Remove last usage of FrameMetrics::mScrollUpdateType. r=botond
https://hg.mozilla.org/integration/autoland/rev/8fc8685f0690
Delete now-unused code. r=botond
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: