Make imgFrame locks counted instead of boolean

RESOLVED FIXED in mozilla18

Status

()

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: joe, Assigned: joe)

Tracking

Trunk
mozilla18
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

6 years ago
Created attachment 656211 [details] [diff] [review]
make locking correct

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)

Updated

6 years ago
Duplicate of this bug: 786445
(Assignee)

Comment 2

6 years ago
Created attachment 656212 [details] [diff] [review]
count imgFrame locks
Assignee: nobody → joe
Attachment #656212 - Flags: review?(justin.lebar+bug)
(Assignee)

Comment 3

6 years ago
Note that I intentionally made the lock count a signed integer so we can catch logic errors.
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

6 years ago
Oh, I thought I did. That's actually how I caught those bugs.
Oh, the assertions are in the second patch!  Duh.
Attachment #656211 - Flags: review?(justin.lebar+bug) → review+
Attachment #656212 - Flags: review?(justin.lebar+bug) → review+
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
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.
You need to log in before you can comment on or make changes to this bug.