Closed
Bug 780260
Opened 12 years ago
Closed 12 years ago
ShadowLayers repaint their image every transaction
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: mattwoodrow, Assigned: mattwoodrow)
References
Details
Attachments
(1 file, 1 obsolete file)
4.43 KB,
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
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+
Assignee | ||
Comment 2•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6609595c84eb
Assignee: nobody → matt.woodrow
This took us from 40fps -> 44fps on the gaia homescreen.
Comment 4•12 years ago
|
||
It also appears to be leaking a single mutex in inbound.
Comment 5•12 years ago
|
||
Backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/fd329615ef3e
Comment 6•12 years ago
|
||
I'm going to blame this for the "ASSERTION: reacquiring already acquired resource" assertions on linux64debug C/R too.
Assignee | ||
Comment 7•12 years ago
|
||
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.
Assignee | ||
Comment 8•12 years ago
|
||
Now using PR_ATOMIC_INCREMENT instead.
Attachment #648817 -
Attachment is obsolete: true
Attachment #654058 -
Flags: review?(jones.chris.g)
Assignee | ||
Comment 9•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=903405a03c6e
Updated•12 years ago
|
Attachment #654058 -
Flags: review?(jones.chris.g) → review+
Updated•12 years ago
|
blocking-basecamp: --- → ?
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d76195e9e2b8
blocking-basecamp: ? → ---
Assignee | ||
Comment 11•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/7dab8a726f44
blocking-basecamp: --- → ?
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d76195e9e2b8 https://hg.mozilla.org/mozilla-central/rev/7dab8a726f44
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Updated•12 years ago
|
blocking-basecamp: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•