Closed Bug 733041 Opened 8 years ago Closed 8 years ago

Zoomed-in scrolling is astonishingly checkerboardy

Categories

(Firefox for Android :: General, defect, P1)

ARM
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 14
Tracking Status
firefox14 --- fixed
firefox15 --- verified
blocking-fennec1.0 --- beta+

People

(Reporter: joe, Assigned: kats)

References

(Blocks 1 open bug)

Details

(Whiteboard: maple [gfx])

Attachments

(2 files, 1 obsolete file)

If you zoom in on a simple page (like a directory listing), we get incredibly checkerboardy, for unknown reasons.
OS: Mac OS X → Android
Hardware: x86 → ARM
This may be a bug in the refreshDisplayPort function; the display port width and height may be incorrectly calculated. I will test my hypothesis once I can stop juggling the patches in my patch queue.
Never mind, my hypothesis was incorrect.
We should try this example with RenderTrace and see which stage is taking longer.
blocking-fennec1.0: --- → ?
This is no longer unusable, just ugly.
No longer blocks: land-maple
blocking-fennec1.0: ? → beta+
Priority: -- → P1
Whiteboard: maple → maple [gfx]
One possible explanation for this is that we try to keep a constant area displayport. This means that when we are zoomed out the displayport will have more room above and below. When we zoom in this value drops to +300 pixels.
Depends on: 737553
We need to figure out of this is still happening or if it's been fixed.
It should still be happening in the default setup, since the FixedMargin strategy that is set as default still does the displayport area-conservation thing which results in less vertical margin when zoomed in. If you change the gfx.displayport.strategy pref to 1 and restart this should no longer manifest because the velocity-bias strategy doesn't do that area-conservation thing. This should be resolved when I switch over to using the velocity-bias as the default, so I'll steal this bug.
Assignee: jmuizelaar → bugmail.mozilla
Increase size of velocity-bias and make it the default. This outperforms the fixed-margin strategy overall, with the various latency fixes applied. Latency due to ShowPress/touchstart still needs to be reduced further to get more gains though.
Attachment #613329 - Flags: review?(chrislord.net)
Build with this patch and all the latency patches applied is at https://people.mozilla.com/~kgupta/tmp/vbias15.apk
Comment on attachment 613329 [details] [diff] [review]
Switch to velocity-bias as default

Actually better hold off on this, JP is seeing a lot more checkerboarding with this on the GN. I'll investigate more.
Attachment #613329 - Flags: review?(chrislord.net)
(In reply to Kartikaya Gupta (:kats) from comment #10)
> Actually better hold off on this, JP is seeing a lot more checkerboarding
> with this on the GN. I'll investigate more.

This seemed to be at least partially a result of the touch event handlers on nytimes.com. Filed bug 743736 to track it.
Maybe this patch belongs on a different, but I'm lazy... :)
Attachment #613646 - Flags: review?(chrislord.net)
Attachment #613329 - Attachment is obsolete: true
Attachment #613647 - Flags: review?(chrislord.net)
Comment on attachment 613646 [details] [diff] [review]
(1/2) Split the velocity-bias buffer so we keep a little in the reverse direction

Review of attachment 613646 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me.
Attachment #613646 - Flags: review?(chrislord.net) → review+
Comment on attachment 613647 [details] [diff] [review]
(2/2) Turn on velocity-bias as default

Review of attachment 613647 [details] [diff] [review]:
-----------------------------------------------------------------

Fine, though it'd be nice if we could avoid possible creating a redundant DisplayPortCalculator (when the pref isn't the default).
Attachment #613647 - Flags: review?(chrislord.net) → review+
(In reply to Chris Lord [:cwiiis] from comment #15)
> 
> Fine, though it'd be nice if we could avoid possible creating a redundant
> DisplayPortCalculator (when the pref isn't the default).

It seems hard to do that without leaving the strategy as null initially (until we find out what the pref is), and I'd rather not do that in case we hit NPEs.


https://hg.mozilla.org/integration/mozilla-inbound/rev/d9b40fa434db
https://hg.mozilla.org/integration/mozilla-inbound/rev/b78eb58c2900
Target Milestone: --- → Firefox 14
Verified/fixed on:
Nightly Fennec 15.0a1 (2012-04-25)
Device: HTC Desire Z
OS: Android 2.3.3
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.