Awesomescreen + Preferences Screens: jerky, text disappears

VERIFIED FIXED

Status

defect
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: tarend, Assigned: mfinkle)

Tracking

({regression})

Firefox Tracking Flags

(fennec2.0b4+)

Details

Attachments

(3 attachments)

Reporter

Description

9 years ago
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
Dupe of bug 622847, even if the situation has got worse. There is work happening in bug 622847
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 622847
Not a duplicate  of bug 622847. I disabled the scroll indicators and the blinking text still happened
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
also affects awesomescreen.
tracking-fennec: --- → ?
Keywords: regression
Summary: Preferences Screens: jerky, text disappears → Awesomescreen + Preferences Screens: jerky, text disappears
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
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
Posted patch patchSplinter Review
This is a fix based on a suggestion from roc. Robert also questioned whether Android is double buffering any of our rendering.
Assignee: nobody → mark.finkle
Attachment #505159 - Flags: review?(mwu)
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
tracking-fennec: ? → 2.0b4+
Duplicate of this bug: 627161
I don't see any noticeable preformance issues with the patch. Pushing to try
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?
(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 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?
Attachment #505159 - Flags: review?(mwu) → review+
pushed:
http://hg.mozilla.org/mozilla-central/rev/5ae2d5625960
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED

Comment 17

8 years ago
Verified as fixed on Mozilla /5.0 (Android;Linux armv7l;rv:2.0b10pre) Gecko/20110120Firefox/4.0b10pre Fennec /4.0b4pre with Samsung Galaxy S
Status: RESOLVED → VERIFIED
Posted patch backoutSplinter Review
Bug 627399 fixed this in a much better way. We do not need to buffer anymore.
Attachment #505827 - Flags: review?(blassey.bugs)
Attachment #505827 - Flags: review?(blassey.bugs) → review+
pushed:
http://hg.mozilla.org/mozilla-central/rev/fe04d3537b36

Needs to be re-verified
Status: VERIFIED → RESOLVED
Last Resolved: 8 years ago8 years ago

Comment 20

8 years ago
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)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.