Closed Bug 1070426 Opened 5 years ago Closed 5 years ago
Frame::Set Has No Alpha() until we unlock the img Frame
Just like in bug 1069652, I'm trying to address issues that arise from imgFrame objects being shared by multiple RawAccessRefs. It seems wise to defer imgFrame::SetHasAlpha() until we unlock, just as we did with imgFrame::Optimize(), since it also replaces mImageSurface.
Summary: Defer imgFrame::SetHasAlpha() until we unlock the imgFrame → Defer imgFrame::SetHasNoAlpha() until we unlock the imgFrame
Here's the patch.
Attachment #8492490 - Flags: review?(mwu)
Comment on attachment 8492490 [details] [diff] [review] Defer imgFrame::SetHasNoAlpha() until we unlock Seth asked me to steal this on irc.
Attachment #8492490 - Flags: review?(mwu) → review+
Thanks Timothy! Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/2b22cf1d48af
FWIW, I didn't get to this because SetHasNoAlpha() is a fairly sketchy call and I was thinking about the right way to go about this. In most cases, I think the decoder should know whether alpha is necessary before outputting decoded data, so this sort of information should be passed on and handled while initializing an imgFrame. Dealing with it after decoding is somewhat backwards. I'm planning to work on decoders later though, so I'll try to kill SetHasNoAlpha later.
(In reply to Michael Wu [:mwu] from comment #4) > In most cases, I > think the decoder should know whether alpha is necessary before outputting > decoded data, so this sort of information should be passed on and handled > while initializing an imgFrame. Yes, that would definitely be preferable; the decoder should provide that information to RasterImage::EnsureFrame.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.