Closed
Bug 786444
Opened 12 years ago
Closed 12 years ago
Make imgFrame locks counted instead of boolean
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla18
People
(Reporter: joe, Assigned: joe)
References
Details
Attachments
(2 files)
6.81 KB,
patch
|
justin.lebar+bug
:
review+
|
Details | Diff | Splinter Review |
5.05 KB,
patch
|
justin.lebar+bug
:
review+
|
Details | Diff | Splinter Review |
As part of bug 486918, I want to make it possible to have multiple downscaled images, but doing that makes necessary to lock an imgFrame multiple times. So, instead of trying to only lock when it's not locked, I'm just going to make imgFrame locks counted, like RasterImage already is. First, I need to make our locking correct - always lock when you're going to GetImageData/GetPaletteData. To do that, I'm introducing an RAII class, which I'm sure will make jrmuizel *ecstatic*.
Attachment #656211 -
Flags: review?(justin.lebar+bug)
Assignee | ||
Comment 2•12 years ago
|
||
Assignee: nobody → joe
Attachment #656212 -
Flags: review?(justin.lebar+bug)
Assignee | ||
Comment 3•12 years ago
|
||
Note that I intentionally made the lock count a signed integer so we can catch logic errors.
Comment 4•12 years ago
|
||
Comment on attachment 656211 [details] [diff] [review] make locking correct > First, I need to make our locking correct - always lock when you're going to > GetImageData/GetPaletteData. Can you add assertions to GetImageData/GetPaletteData that we're locked?
Assignee | ||
Comment 5•12 years ago
|
||
Oh, I thought I did. That's actually how I caught those bugs.
Comment 6•12 years ago
|
||
Oh, the assertions are in the second patch! Duh.
Updated•12 years ago
|
Attachment #656211 -
Flags: review?(justin.lebar+bug) → review+
Updated•12 years ago
|
Attachment #656212 -
Flags: review?(justin.lebar+bug) → review+
Assignee | ||
Comment 7•12 years ago
|
||
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b2dba2108722 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/d3b69fe15ac3
Target Milestone: --- → mozilla18
Comment 8•12 years ago
|
||
Push backed out on suspicion of causing intermittent Android reftest failures like: https://tbpl.mozilla.org/php/getParsedLog.php?id=15640210&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=15638930&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=15639608&tree=Mozilla-Inbound Retriggers are pending and I believe will confirm one of the bugs in the push to be the cause, but we can't afford to keep the tree closed any longer, so backing this out for now. Retrigger results will be at: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=%20reftest&rev=92530b29ac24 Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/28e5dc437921
Comment 9•12 years ago
|
||
Relanded in https://hg.mozilla.org/integration/mozilla-inbound/rev/bed067351ab6 https://hg.mozilla.org/integration/mozilla-inbound/rev/f9506ec6be80 https://hg.mozilla.org/integration/mozilla-inbound/rev/a96be857cca7 on the theory that the Android reftest problem of bug 784278 and bug 792212 was a prefs problem, and you were relying on a pref, and not getting it.
Comment 10•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f9506ec6be80 https://hg.mozilla.org/mozilla-central/rev/bed067351ab6
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•