Last Comment Bug 742081 - WebGL texture load broken does not work after bug 740841
: WebGL texture load broken does not work after bug 740841
Status: NEW
: regression
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: 14 Branch
: x86 Linux
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 740841
  Show dependency treegraph
 
Reported: 2012-04-03 15:45 PDT by Oleg Romashin (:romaxa)
Modified: 2016-07-07 13:14 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Workaround which make it works back (1.03 KB, patch)
2012-04-03 15:47 PDT, Oleg Romashin (:romaxa)
no flags Details | Diff | Splinter Review
fix? (1.40 KB, patch)
2012-04-04 00:19 PDT, Timothy Nikkel (:tnikkel)
romaxa: feedback-
Details | Diff | Splinter Review

Description Oleg Romashin (:romaxa) 2012-04-03 15:45:20 PDT
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
Comment 1 Oleg Romashin (:romaxa) 2012-04-03 15:47:37 PDT
Created attachment 612002 [details] [diff] [review]
Workaround which make it works back
Comment 2 Timothy Nikkel (:tnikkel) 2012-04-03 15:51:36 PDT
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?
Comment 3 Timothy Nikkel (:tnikkel) 2012-04-03 22:16:02 PDT
I backed out bug 740841 for now.
Comment 4 Timothy Nikkel (:tnikkel) 2012-04-04 00:19:33 PDT
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.
Comment 5 Timothy Nikkel (:tnikkel) 2012-04-04 00:20:40 PDT
Testcase that I'm using for testing that I got from Oleg: http://www.everyday3d.com/j3d/demo/004_Glass.html
Comment 6 Oleg Romashin (:romaxa) 2012-04-04 00:37:20 PDT
Comment on attachment 612124 [details] [diff] [review]
fix?

this works fine for me too
Comment 7 Oleg Romashin (:romaxa) 2012-04-04 00:49:12 PDT
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
Comment 8 Timothy Nikkel (:tnikkel) 2012-04-04 01:24:48 PDT
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.
Comment 9 Joe Drew (not getting mail) 2012-04-04 11:00:37 PDT
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.
Comment 10 Boris Zbarsky [:bz] 2012-04-04 11:15:32 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.