Closed Bug 1071686 Opened 10 years ago Closed 10 years ago

Reproducible APZC failure and 300ms scroll delay

Categories

(Core :: Panning and Zooming, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: BenWa, Assigned: kats)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

STR:
1) Shift+reload https://bugzilla.mozilla.org/show_bug.cgi?id=1071156 (I believe it works there because the CC box is scrollable)
2) Position the mouse to the right of the CC box, outside.
3) Fling scroll the page down.

If you have trouble reproducing try to minimize the time between the page load and the fling.
Blocks: apz-desktop
The APZ failure box only flashes on for a few frames for me. I think that might just be because there's a period of time between when we dispatch the repaint request with the displayport and the repaint happens and re-layerizes the content to scroll. During that time the APZ is still updating the transform on the scroll info layer but it doesn't have content so the red box flashes.
(Also just for completeness, you need to enable the FPS counter pref to see the red square)
Here are the relevant layer dumps. The first one in the file is the steady state before scrolling starts. In this case there is a scrollinfo layer with scrollid=5 for the main content with no APZ transform, so no red square. It also doesn't have a displayport (presumably because the initial-displayport code at [1] is ifdef'd to b2g). In the last layer dump in the file, the scrollable content repaint has taken effect, so there is a thebes layer for it, and the APZ transform is applied to that. All the layer dumps in between show the red square because the APZ transform is applied to the container layer but the repaint and relayerization hasn't happened yet.

I suspect we can fix this by expanding the ifdef'd code to run on OS X as well.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?rev=1c9e801f66aa#2772
I verified that removing the #ifdef (so the code is used on all platforms) fixes this problem. Markus has a patch on bug 1009786 that includes this change, so I'll make this block on that. We can dupe it over once that lands.
Depends on: 1009786
Attached patch PatchSplinter Review
In the interests of getting this fixed sooner (and reduce the risk in bug 1009786), I'd like to land this part separately from bug 1009786. Any objections?
Attachment #8504755 - Flags: review?(mstange)
Comment on attachment 8504755 [details] [diff] [review]
Patch

No objections, but you'll probably also need the reftest fuzziness annotations from attachment 8494800 [details] [diff] [review].
Attachment #8504755 - Flags: review?(mstange) → review+
I did a try push to check [1]; so far the reftests on desktop platforms are green. Maybe the fuzziness was coming from a different part of your patch?

[1] https://tbpl.mozilla.org/?tree=Try&rev=30d9b096ea77
Oh, right, your patch doesn't cause them because it has no effect on platforms without APZ.
Assignee: nobody → bugmail.mozilla
https://hg.mozilla.org/mozilla-central/rev/1a5153ae014f
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.