Closed Bug 909752 Opened 11 years ago Closed 10 years ago

Too much jank while panning text heavy pages

Categories

(Core :: Panning and Zooming, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 931028

People

(Reporter: jimm, Unassigned)

References

Details

Attachments

(1 obsolete file)

STR:

1) open a page of text
2) zoom in maybe 50%
3) place your finger on an identifiable origin in the page
4) pan in a small circular movement

result: the origin will skip around underneath your finger.
Attached image large image (obsolete) —
good test case
Blocks: 915724
No longer blocks: metro-apzc
<bbondy> jimm: btw we can get rid of the jumpy behavior when zoomed for panning via a 'wrong fix'.  Basically if you comment out the call to setResolution then it works, but when you are zoomed it is blurry.
<bbondy> not bad nor noticeable to most people though
<MarcoM> Brian and Jim, I'll follow up with Brad at the beginning of October to double-check on availability.
<jimm> hmm, I didn't notice the blurryness when zoomed bug was fixed
<bbondy> maybe we can just do that temporarily?
<bbondy> I didn't notice either but kats said it existed :)
<bbondy> jimm: commenting out this line I think: http://dxr.mozilla.org/mozilla-central/source/browser/metro/base/content/bindings/browser.js#l593
<bbondy> will make it work ok
Whiteboard: [preview-triage]
This blocks a story which blocks. I'd consider it a work bug really. We can triage all open apz bugs when we feel things are starting to solidify up.
Whiteboard: [preview-triage]
I can reproduce this but I'm not 100% sure what's causing it. My first guess was that UpdateScrollOffset was getting called but it's not - I dumped the mFrameMetrics.mScrollOffset for every frame that was composited and there were no bad discontinuities in those numbers. So the APZC's internal frame metrics are fine.

The page jumps at points where a layers update comes in, and for some reason the frame metrics in the layers update isn't quite the same as what we requested. For example:

APZC: 12598348 requesting content repaint: i=(10 1) cb=(0 0 1920 1080) dp=(-238.750 -360.384 1432.500 1200.000) v=(0.000 0.000 1376.000 774.000) s=(547.952 360.384) sr=(0.000 0.000 1920.000 1200.000) z=(1.395 1.440 1.440 2.009)
APZC: 12598348 got a NotifyLayersUpdated with aIsFirstPaint=0: i=(10 1) cb=(0 0 1920 1080) dp=(-238.200 -359.717 1432.000 1200.000) v=(0.000 0.000 1376.000 774.000) s=(546.817 359.767) sr=(0.000 0.000 1920.000 1200.000) z=(1.395 1.440 1.440 2.009)

Note here that the scroll offset is off by a little bit between the request and the response. Although the new scroll offset doesn't get set in the APZC, the async transform is calculated using that new scroll offset as a base (i.e. in GetCurrentAsyncTransform) so if the scroll offset is wrong then that might cause the jitter. This is the most likely suspect at the moment.

I've never run into a problem before where the scroll offset provided in the layers update was wrong, since it comes directly from layout which knows definitively what it used so this is puzzling to me.
Moving this to P&Z for now, although eventually it might end up in Layout.
Component: Pan and Zoom → Panning and Zooming
Product: Firefox for Metro → Core
I'm not able to reproduce this now, aside from the repaint jank we see in most operations. Not blocking for now.
(In reply to Jim Mathies [:jimm] from comment #6)
> I'm not able to reproduce this now, aside from the repaint jank we see in
> most operations. Not blocking for now.

nm, I'm seeing this on pages of text. large images seem to do better, which is what I was testing on previously.
Whiteboard: [block28]
I don't see this anymore with my other patches (bug 902505, bug 927027) applied.
This seems to be back off tip from yesterday.
Discussed with jimm on IRC - he's seeing jank (missed frames of composition) rather than jitter (page is getting painted in the wrong spot). Jitter is a correctness problem whereas jank is a performance problem so the approach we take to tackle it is different.
Also the specific example was on techmeme.com - when panning while a finger is down there is fairly heavy jank (I see this too) but flings are pretty smooth. Setting the axis lock mode to 1 (always lock) doesn't help much.
Summary: Panning while zoomed jitters around the pan origin → Too much jank while panning around
Attachment #801227 - Attachment is obsolete: true
Summary: Too much jank while panning around → Too much jank while panning text heavy pages
No longer blocks: 915724
Blocks: metro-apzc
Depends on: 931028
Whiteboard: [block28] → [beta28]
Blocks: metrov1backlog, metrov1omtc&apzc
No longer blocks: metro-apzc
Per discussions between marcom and milan, we're requesting tracking on the remaining "big issues" related to apzc for metrofx, which is riding the 28 train. We expect these will get fixed during the long aurora train ride.

This bug is related to jank when panning pages of text. This may be a dupe of bug 931028, which is already tracked.
Similar to Bug 907179 we would like to see an assignee and would like to know is this is a block for shipping. I guess we don't understand how much jank is acceptable and what would have a large enough impact to require tracking?
Flags: needinfo?(jmathies)
(In reply to Benjamin Kerensa [:bkerensa] from comment #13)
> Similar to Bug 907179 we would like to see an assignee and would like to
> know is this is a block for shipping. I guess we don't understand how much
> jank is acceptable and what would have a large enough impact to require
> tracking?

Actually this is more similar to bug 931028 which blocks this bug. There we found that on about:start we were painting way too much when scrolling. This bug is all about looking at our scroll painting on normal pages to ascertain whether we have the same problem. Generally scroll perf (and jank issues) have gotten worse over the month or so with all the changes to apzc. So this bug is about investigating our painting habits on common web pages to be sure painting isn't doing anything silly. It can wait on the outcome of bug 931028.
Flags: needinfo?(jmathies)
Whiteboard: [beta28] → [beta28][gfx]
We're tracking bug 931028, no need to track here until there's something more actionable or that would block release.
Whiteboard: [beta28][gfx] → [beta28] [gfx]
Is there a specific testcase for this bug?
http://www.gutenberg.org/files/11/11-h/11-h.htm

This is a pretty good page for testing scroll issues.
I was just testing a different patch on Metro and noticed that if you are scrolling around on the Alice in Wonderland page fully zoomed out, then the paint flashing behaviour is what I would expect (i.e. chunks of the page are drawn and older chunks are reused). If you zoom in even a little bit then the entire area is redrawn every time. That probably contributes quite a bit to jank.
(In reply to Jim Mathies [:jimm] from comment #17)
> http://www.gutenberg.org/files/11/11-h/11-h.htm
> 
> This is a pretty good page for testing scroll issues.

For a slightly heavier page, http://www.techmeme.com/ is good too.
Whiteboard: [beta28] [gfx] → [metro] [beta28] [gfx]
No longer blocks: metrov1backlog, metrov1omtc&apzc
Status: NEW → RESOLVED
Closed: 10 years ago
No longer depends on: 931028
Resolution: --- → DUPLICATE
Whiteboard: [metro] [beta28] [gfx]
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: