I see that webgl stopped working after landing fix from bug 740841 we always return with error on this condition: http://hg.mozilla.org/mozilla-central/annotate/d698e656b1e0/image/src/RasterImage.cpp#l893 because mDecoder is not null
Created attachment 612002 [details] [diff] [review] Workaround which make it works back
So if we are asked to decode with different flags and we have a decoder already then should we shutdown the existing decoder and start a new one with the requested flags?
I backed out bug 740841 for now.
Created attachment 612124 [details] [diff] [review] fix? Something like this seems to fix it. But I didn't do my homework on imglib to see if this is 100% kosher.
Testcase that I'm using for testing that I got from Oleg: http://www.everyday3d.com/j3d/demo/004_Glass.html
Comment on attachment 612124 [details] [diff] [review] fix? this works fine for me too
Comment on attachment 612124 [details] [diff] [review] fix? oh, no, tested it carefully, and found that textures now corrupted on half... sounds like we interrupting decoding and getting broken texture at the end
Sadly that makes sense. If there is a decoder already that means there is probably another consumer around of the same image but who wants different decode flags.
If we're already doing an asynchronous decode, and we want to do a synchronous decode for a different pixel format, we are in for a real heap of trouble, since the other decoders are waiting on notifications from the decode. If we have all of the image data, we're OK: we can flush all the data to the decoder synchronously, shut it down, and then open a new decoder for the new format. If we don't have all the image data, we should just refuse to fulfill the request.
If we don't have all the data, I'd think the webgl code should not be asking for it to start with. Certainly 2d canvas is supposed to silently do nothing when asked to draw a still-loading image.
or
