Closed Bug 662521 Opened 9 years ago Closed 7 years ago
After scrolling lines (vert
. scroll) and characters (horz . scroll) visibly snap to full pixels
Still unresolved - see Bug 630743. Opening a new bug since 630743 is closed while the problem still exists. (1) scroll text Result: text lines jump slightly before they settle (documented in http://dl.dropbox.com/u/686313/scrolling.webm ) Expected: no jumping lines
related/dup of bug 656041?
Thomas, what do you want to do about this bug?
So this seems to be present in the current v5 beta, though I can't reproduce in v6 or v7.
(In reply to comment #3) > So this seems to be present in the current v5 beta, though I can't reproduce > in v6 or v7. If this is the case, we can close the bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
I can still reproduce this in our latest nightly
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can reproduce this as well at http://m.theatlantic.com/infocus/ 1. go to http://m.theatlantic.com/infocus/ 2. pan down fast 3. and let it settle The text wiggles a little before completely stopping.
This is pretty awful. I see it on a majority of the pages I read in nightly builds on both a Galaxy Tab and a Transformer. I know advocacy comments aren't terribly helpful, but this is the number one reason I have to put the tablet down after using it for a while. It's almost nauseating. We would never let this ship on desktop and I don't think we should be shipping this on mobile. Basic readability issues while scrolling is not a something we should be pushing off.
Fwiw, I hardly notice this issue.
I completely agree with Comment 7. It is clearly visible on a Galaxy Tab 7" or 10.1". It is a bit more subtle on a smaller screen, but makes us look "blurry" and definitely not professional. I tried to prioritize this bug before but got overruled. I am nominating this bug again and hope we can get it fixed soon. It is because of this and several other "subtle" issues that we don't appear as smooth, fast, and professional as we should be, especially compared to other browsers out there. We can't afford these bugs - they are not "just" polish but are part of our user experience.
I wonder if there's a relationship with bug 501028 here. It seems to me this is more likely a Core->Layout:text issue or Graphics issue to me.
Doug and I looked at this today and I discussed this with dbaron on Friday. A possible theory is that during scrolling we arrive at a sub-pixel scroll offset and when we re-render we snap lines to whole pixels, causing the line jumping. This also happens with vertical scrolling and individual characters (some, not all) jump a pixel.
Let's see if bug 681192 affects it.
doug is testing your patch
I applied the 3 patches in the bug (as-is) and I don't see a major improvement (build temporary here: people.mozilla.org/~dougt/fennec.apk).
Bug 681192 is not quite complete yet. Alongside the patches in that bug, we need to also choose final zoom levels more carefully ... something like https://bugzilla.mozilla.org/show_bug.cgi?id=681192#c15.
(but we may also need to bump appunitsperdevpixel up, to 240 or something) Andreas says that this bug happens with no zoom (1 CSS pixel == 1 device pixel) so this probably doesn't need bug 681192 though.
Assignee: nobody → snorp
tracking-fennec: 9+ → +
Robert, is it your thinking that this would be "fixed" by bug 681192, that this might be "improved" by bug 681192, or that we should try to tackle this as a distinct issue until we have a fix for bug 681192?
How do we get to fixed?
Summary: Text wiggles after scrolling → Text wiggles after scrolling (Mobile)
This still looks mighty crappy with a nightly build in my tablet. I will make the title a bit clearer.
Summary: Text wiggles after scrolling (Mobile) → After scrolling lines (vert. scroll) and characters (horz. scroll) visibly snap to full pixels
Tracking '-' as this issue does not reproduce in Native trunk.
tracking-fennec: + → -
Status: NEW → RESOLVED
Closed: 9 years ago → 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.