[Webkit-unassigned] [Bug 108892] Passing alpha to DeferredImageDecoder once decoding completes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=108892





--- Comment #29 from Min Qin <qinmin at chromium.org>  2013-02-14 11:45:16 PST ---
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #25)
> > > > (In reply to comment #24)
> > > > > If there's some chance the mutex isn't necessary, I wish we hadn't landed this.
> > > > 
> > > > 
> > > > I am wondering whether there will be a case that:
> > > > if (decoder->frameHasAlphaAtIndex(0)) {
> > > >   read_pixelref();  
> > > > }
> > > > However, on another thread where alpha value just got set, the skbitmap still haven't been fully decoded yet. So we need a memory barrier there and Mutex should do that.
> > > 
> > > That will not be the case. alpha value is known only after an image is fully decoded.
> > 
> > Would multi processor cache hurt?
> 
> I don't know what this means.
> 
> But reading Stephen's comments that get me thinking that mutex might not be necessary. The value is either true or false and it doesn't hurt to have alpha == true. So even if we don't protect it and assignment comes while decode() is running the worst case is alpha is true when it should be false, which is benign anyway.

Yes, for this case we are probably fine since the starting value is always true, and will only be changed to false later on.
However, if there is a case that we can change the value from false to true, then it will be different. Processor A changes the value from false to true. At the same time processor B checks its own cache and sees that it is false, so it decides to do nothing. But since that is not going to happen, i think we are probably safe.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.