Zoomed-in scrolling is astonishingly checkerboardy

VERIFIED FIXED in Firefox 14

Status

()

P1
normal
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: joe, Assigned: kats)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 14
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox14 fixed, firefox15 verified, blocking-fennec1.0 beta+)

Details

(Whiteboard: maple [gfx])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
blocking-fennec1.0: --- → ?
(Reporter)

Comment 4

7 years ago
This is no longer unusable, just ugly.
No longer blocks: 725095
blocking-fennec1.0: ? → beta+
Priority: -- → P1
Whiteboard: maple → maple [gfx]
Blocks: 729391
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.

Updated

7 years ago
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
Created attachment 613329 [details] [diff] [review]
Switch to velocity-bias as default

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.
Created attachment 613646 [details] [diff] [review]
(1/2) Split the velocity-bias buffer so we keep a little in the reverse direction

Maybe this patch belongs on a different, but I'm lazy... :)
Attachment #613646 - Flags: review?(chrislord.net)
Created attachment 613647 [details] [diff] [review]
(2/2) Turn on velocity-bias as default
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
status-firefox14: --- → fixed
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/mozilla-central/rev/d9b40fa434db
https://hg.mozilla.org/mozilla-central/rev/b78eb58c2900
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 18

6 years ago
Verified/fixed on:
Nightly Fennec 15.0a1 (2012-04-25)
Device: HTC Desire Z
OS: Android 2.3.3
Status: RESOLVED → VERIFIED
status-firefox15: --- → verified
You need to log in before you can comment on or make changes to this bug.