486014 - GMail storage counter flickers with each update

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[u279076]

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.

Comment 1

[u279076]

Attachment: Screnshot of the GMail counter

Comment 2

[Geoff Gustafson]

This may be the same thing I see with this somewhat minimized test case:
http://www.mitwhiz.com/fennec/fennec-test001.html

Comment 3

[Ben Combee (:bcombee)]

I verified the flicker with Win32 desktop Fennec build.  Looking into mozAfterPaint messages.

Comment 4

[Benjamin Stover (:stechz)]

Attachment: Test case: change of innerHTML

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

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Switching to a more appropriate component.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Ben - Perhaps we should be doing a tiny bit of coalescing in Fennec, since the second update is happening so fast (is that 4ms ?)

Comment 8

[Benjamin Stover (:stechz)]

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?

Comment 9

[Benjamin Stover (:stechz)]

Attachment: Tile rendering now flushes

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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 11

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 12

[Stuart Parmenter]

Comment on attachment 401091 [details] [diff] [review]
Tile rendering now flushes

please get rid of the XXX comment

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
https://hg.mozilla.org/mobile-browser/rev/287e40af0826

Comment 14

[Aakash Desai [:aakashd]]

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