703821 - Consecutive draw events shouldn't be squashed together if the compositor is in use

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Patrick Walton (:pcwalton)]

There's logic in widget/src/android that squashes together draw events by throwing out all but the first one in order to optimize redraws. But that's only correct if every draw event covers the entire screen. This was the case in XUL Fennec (in software mode anyway), but the Java compositor is smarter than that -- its draw events only update dirty rects. Unfortunately, the optimization mentioned previously causes many of its draw events to get dropped.

This patch turns off the draw squashing if the compositor is in use. In my testing it fixes many of the repaint bugs.

Comment 1

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch.

Proposed patch attached.

Comment 2

[Doug Turner (:dougt)]

https://hg.mozilla.org/mozilla-central/rev/ea5e1f4e996a

Comment 3

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

FYI: This patch caused a ~50ms regression in Txul and a ~400ms regression in Tdhtml. I assume this is because we are painting more than before.

Comment 4

[Alex Pakhotin (:alexp)]

(In reply to Doug Turner (:dougt) from comment #2)
> https://hg.mozilla.org/mozilla-central/rev/ea5e1f4e996a

This seems to have caused a significant input slowdown - see bug 705166.