Closed Bug 780260 Opened 7 years ago Closed 7 years ago

ShadowLayers repaint their image every transaction

Categories

(Core :: Graphics: Layers, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: mattwoodrow, Assigned: mattwoodrow)

References

Details

Attachments

(1 file, 1 obsolete file)

This is causing significant slow downs when panning around the homescreen on b2g.

Attached patch adds serial numbers to Images and skips repainting the image if it hasn't changed.
Attachment #648817 - Flags: review?(jones.chris.g)
Comment on attachment 648817 [details] [diff] [review]
Add a serial number to images to identify them

I would feel more comfortable with this if you used uint64_t.

r=me with that.  Nice patch :).
Attachment #648817 - Flags: review?(jones.chris.g) → review+
This took us from 40fps -> 44fps on the gaia homescreen.
It also appears to be leaking a single mutex in inbound.
I'm going to blame this for the "ASSERTION: reacquiring already acquired resource" assertions on linux64debug C/R too.
So, I guess we can't have a global Mutex object here :(

Attempting to allocate one the first time we create an image seems like it would have the exact same race condition problems that we will be using it to avoid.

Though it occurs to me that we'd never use images allocated on different threads with the same ImageLayer, so maybe we can remove the Mutex entirely and not worry about potential races.
Now using PR_ATOMIC_INCREMENT instead.
Attachment #648817 - Attachment is obsolete: true
Attachment #654058 - Flags: review?(jones.chris.g)
Attachment #654058 - Flags: review?(jones.chris.g) → review+
blocking-basecamp: --- → ?
https://hg.mozilla.org/mozilla-central/rev/d76195e9e2b8
https://hg.mozilla.org/mozilla-central/rev/7dab8a726f44
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
blocking-basecamp: ? → ---
You need to log in before you can comment on or make changes to this bug.