627087 - Awesomescreen + Preferences Screens: jerky, text disappears

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Thomas Arend [:tarend]]

Seen on today's nightly 20110119

See attached video
STR: (1) go to Preferences Pane, choose any of the tabs, (2) scroll up and down

Comment 1

[Thomas Arend [:tarend]]

Video is here:
https://docs.google.com/uc?id=0B9_n_sTfO0TaMDIxMDU2ZmYtY2UwMS00OTJiLTljNzgtMDhmMjhlY2QzYjIw&export=download&authkey=CJjk06cO&hl=en

Comment 2

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

Dupe of bug 622847, even if the situation has got worse. There is work happening in bug 622847

Comment 3

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

Not a duplicate  of bug 622847. I disabled the scroll indicators and the blinking text still happened

Comment 4

[Aaron Train [:aaronmt]]

Perhaps related, perhaps not, I am unable to open the site-identity button with the same build in one situation.

STR: 
1. Go to the Fennec Start Page
2. Scroll down a tad so that the location bar is half way under the Android status bar
3. Tap the site-identity button

ER: Site identify opens
AR: Looks like it is opening behind content, and or just not rendering properly.

Device: HTC Google Nexus One

Comment 5

[Tony Chung [:tchung]]

Attachment: awesomescreen dissapears screenshot

also affects awesomescreen.

Comment 6

[Wesley Johnston (:wesj)]

Seems to have occurred between:

http://hg.mozilla.org/mozilla-central/rev/e807269acaa3
and
http://hg.mozilla.org/mozilla-central/rev/809aded51aad

Comment 7

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

One of these csets:
1d293c9ffa95	Robert O'Callahan — Bug 621601. Part 3: Implement EndEmptyTransaction for D3D10. r=bas,a=joe
	4fc581f1ff00	Robert O'Callahan — Bug 621601. Part 2: Implement EndEmptyTransaction for D3D9. r=bas,a=joe
	a18080aa75d6	Robert O'Callahan — Bug 621601. Part 1: Change empty transaction API to EndEmptyTransaction. r=bas,tnikkel,a=joe


I'll try to build them individually

Comment 8

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

It's this cset:

http://hg.mozilla.org/mozilla-central/rev/a18080aa75d6
Robert O'Callahan — Bug 621601. Part 1: Change empty transaction API to EndEmptyTransaction. r=bas,tnikkel,a=joe

Comment 9

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

Attachment: patch

This is a fix based on a suggestion from roc. Robert also questioned whether Android is double buffering any of our rendering.

Comment 10

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

More from roc on IRC:
<roc>: BUFFER_BUFFERED might cost performance
<roc>: you'll want to measure that carefully
<roc>: if you look at BasicLayerManager::EndTransactionInternal computing useDoubleBuffering, there are optimizations to disable double-buffering when we don't need it
<roc>: if you're lucky you'll hit one of those
<roc>: for normal Web rendering

Comment 12

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

I don't see any noticeable preformance issues with the patch. Pushing to try

Comment 13

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

In BasicLayerManager::EndTransactionInternal, see the comment "If we're doing manual double-buffering ...".

When you get this flicker, I'm pretty sure it's because useDoubleBuffering is false and mTransactionIncomplete is true. So we've tried to do an "empty transaction" (without repainting any ThebesLayers), but it didn't work so we're going to carry on and do a normal paint which will fix everything up, but in the meantime we've drawn bogus incomplete stuff to the destination context.

Now Android's nsWindow currently passes BUFFER_NONE to BasicLayers, which means that Android is promising that the platform handles double-buffering for us (like Mac does). In that case that bogus incomplete stuff should not be reaching the screen. So the question is, does Android really handle double-buffering for us, and if so, why is this bug happening?

Comment 14

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

(In reply to comment #12)
> I don't see any noticeable preformance issues with the patch. Pushing to try

Hmm, no Talos stuff for Android...

Comment 15

[Michael Wu [:mwu]]

Comment on attachment 505159 [details] [diff] [review]
patch

Well if it works, why not.

Our 2d drawing path expects the entire paint to be completed when it starts. How do we tell when there's a paint which shouldn't be shown?

Comment 16

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

pushed:
http://hg.mozilla.org/mozilla-central/rev/5ae2d5625960

Comment 17

[ahoza]

Verified as fixed on Mozilla /5.0 (Android;Linux armv7l;rv:2.0b10pre) Gecko/20110120Firefox/4.0b10pre Fennec /4.0b4pre with Samsung Galaxy S

Comment 18

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

Attachment: backout

Bug 627399 fixed this in a much better way. We do not need to buffer anymore.

Comment 19

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

pushed:
http://hg.mozilla.org/mozilla-central/rev/fe04d3537b36

Needs to be re-verified

Comment 20

[Andreea Pod]

Verified fixed on build: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110511 Firefox/6.0a1 Fennec/6.0a1 
Device: LG Optimus 2X (Android 2.2)