Closed
Bug 733041
Opened 11 years ago
Closed 11 years ago
Zoomed-in scrolling is astonishingly checkerboardy
Categories
(Firefox for Android Graveyard :: General, defect, P1)
Tracking
(firefox14 fixed, firefox15 verified, blocking-fennec1.0 beta+)
VERIFIED
FIXED
Firefox 14
People
(Reporter: joe, Assigned: kats)
References
Details
(Whiteboard: maple [gfx])
Attachments
(2 files, 1 obsolete file)
4.35 KB,
patch
|
cwiiis
:
review+
|
Details | Diff | Splinter Review |
2.08 KB,
patch
|
cwiiis
:
review+
|
Details | Diff | Splinter Review |
If you zoom in on a simple page (like a directory listing), we get incredibly checkerboardy, for unknown reasons.
Updated•11 years ago
|
OS: Mac OS X → Android
Hardware: x86 → ARM
Assignee | ||
Comment 1•11 years ago
|
||
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.
Assignee | ||
Comment 2•11 years ago
|
||
Never mind, my hypothesis was incorrect.
Comment 3•11 years ago
|
||
We should try this example with RenderTrace and see which stage is taking longer.
Reporter | ||
Updated•11 years ago
|
blocking-fennec1.0: --- → ?
Reporter | ||
Comment 4•11 years ago
|
||
This is no longer unusable, just ugly.
No longer blocks: land-maple
Updated•11 years ago
|
blocking-fennec1.0: ? → beta+
Updated•11 years ago
|
Priority: -- → P1
Updated•11 years ago
|
Whiteboard: maple → maple [gfx]
Comment 5•11 years ago
|
||
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•11 years ago
|
Blocks: checkerboarding
Comment 6•11 years ago
|
||
We need to figure out of this is still happening or if it's been fixed.
Assignee | ||
Comment 7•11 years ago
|
||
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
Assignee | ||
Comment 8•11 years ago
|
||
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)
Assignee | ||
Comment 9•11 years ago
|
||
Build with this patch and all the latency patches applied is at https://people.mozilla.com/~kgupta/tmp/vbias15.apk
Assignee | ||
Comment 10•11 years ago
|
||
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)
Assignee | ||
Comment 11•11 years ago
|
||
(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.
Assignee | ||
Comment 12•11 years ago
|
||
Maybe this patch belongs on a different, but I'm lazy... :)
Attachment #613646 -
Flags: review?(chrislord.net)
Assignee | ||
Comment 13•11 years ago
|
||
Attachment #613329 -
Attachment is obsolete: true
Attachment #613647 -
Flags: review?(chrislord.net)
Comment 14•11 years ago
|
||
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 15•11 years ago
|
||
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+
Assignee | ||
Comment 16•11 years ago
|
||
(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
Comment 17•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d9b40fa434db https://hg.mozilla.org/mozilla-central/rev/b78eb58c2900
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 18•11 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
Updated•2 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•