The default bug view has changed. See this FAQ.

WebGL texture load broken does not work after bug 740841

NEW
Unassigned

Status

()

Core
ImageLib
5 years ago
9 months ago

People

(Reporter: romaxa, Unassigned)

Tracking

(Blocks: 1 bug, {regression})

14 Branch
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
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?
tracking-firefox14: --- → ?
I backed out bug 740841 for now.
tracking-firefox14: ? → ---
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.
Attachment #612124 - Flags: feedback?(joe)
Testcase that I'm using for testing that I got from Oleg: http://www.everyday3d.com/j3d/demo/004_Glass.html
(Reporter)

Comment 6

5 years ago
Comment on attachment 612124 [details] [diff] [review]
fix?

this works fine for me too
Attachment #612124 - Flags: feedback+
(Reporter)

Comment 7

5 years ago
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
Attachment #612124 - Flags: feedback+ → feedback-
Attachment #612124 - Flags: feedback?(joe)
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.
Version: Trunk → 14 Branch
You need to log in before you can comment on or make changes to this bug.