Closed Bug 486014 Opened 11 years ago Closed 10 years ago

GMail storage counter flickers with each update

Categories

(Firefox for Android Graveyard :: General, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
fennec1.0b4

People

(Reporter: ashughes, Assigned: stechz)

Details

Attachments

(3 files)

TEST BUILD: Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv: 1.9.2a1pre) Gecko/20090312 Fennec/1.0b1

There is a counter under the "Lots of space" heading on GMail's main page.  This counter counts up the amount of storage available.  In Firefox 3, the counter updates smoothly.  On Fennec, the numbers disappear for half a second before updating (i.e. it flickers).

I've attached a screenshot of the element in question.
This may be the same thing I see with this somewhat minimized test case:
http://www.mitwhiz.com/fennec/fennec-test001.html
I verified the flicker with Win32 desktop Fennec build.  Looking into mozAfterPaint messages.
Assignee: nobody → webapps
It looks like MozAfterPaint is fired two times when innerHTML is changed: the first one blanks out the text and the next renders the new innerHTML.  So we get a flicker.

Time since last paint 994 
Time since last paint 4 
Time since last paint 999 
Time since last paint 4 
Time since last paint 995 
Time since last paint 4
Component: General → Layout: View Rendering
Product: Fennec → Core
QA Contact: general → layout.view-rendering
Switching to a more appropriate component.
From IRC:

<roc>: I bet you get blank text because you don't flush reflows when calling drawWindow
<roc>: the MozAfterPaints track invalidation, not painting, so they're not coalesced
Ben - Perhaps we should be doing a tiny bit of coalescing in Fennec, since the second update is happening so fast (is that 4ms ?)
For now, coalescing might be our best solution for solving the flicker issue.

@roc: on IRC Mark mentioned that there may be a compositor patch that will fix this issue in the future.  I'd like to know when we've landed the patch so our hack can be removed.  Is it bug 374980?
This patch fixes the flicker problem by removing the DO_NOT_FLUSH flag.  After experimenting, the patch does not seem to cause a perceptible perf regression during loading.
Attachment #401091 - Flags: review?(mark.finkle)
There is no patch, just a plan. There is no bug filed specifically for that phase, but when there is a bug, it will be linked into bug 374980.
Comment on attachment 401091 [details] [diff] [review]
Tile rendering now flushes

this is fine by me, but I wanted stuart to sign off too. He spent a lot of time with this part of the code.
Attachment #401091 - Flags: review?(pavlov)
Attachment #401091 - Flags: review?(mark.finkle)
Attachment #401091 - Flags: review+
Flags: blocking1.9.2?
Comment on attachment 401091 [details] [diff] [review]
Tile rendering now flushes

please get rid of the XXX comment
Attachment #401091 - Flags: review?(pavlov) → review+
pushed:
https://hg.mozilla.org/mobile-browser/rev/287e40af0826
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → General
Flags: blocking1.9.2?
Product: Core → Fennec
QA Contact: layout.view-rendering → general
Target Milestone: --- → B4
verified FIXED (using the attached testcase and gmail) on builds:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2a2pre) Gecko/20090922 Fennec/1.0a3

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.2a2pre) Gecko/20090922
Fennec/1.0b4pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.