This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The UA normally wants to defer decoding of (currently) invisible images until they're actually needed, as an optimization. However, this makes it difficult to implement HTMLImageElement's "complete" attribute, since we need to decode the entire image to know if it's complete or not. Both WebKit and Gecko lie about "complete" right now, in part due to the privacy leak referred to here: https://bugs.webkit.org/show_bug.cgi?id=28832
Do you do the decoding synchronously once the script accesses .width and .height?
(In reply to comment #1) > Do you do the decoding synchronously once the script accesses .width and > .height? No, we get this at the layouting stage, but it's cheap since we can get the geometry from the header (for sane image formats, anyway.)
So you decode enough of the image to know its width and height, then set .complete to true? What do you do with drawImage() when it's called with an HTMLImageElement that is not completely decoded but that has complete=true? Is there any way to know when a very large hidden image will be completely available for rendering on a canvas?
> What do you do with drawImage() Gecko will synchronously complete the decode there, I believe. To be clear, "complete" in Gecko means that we have all the raw image bytes. We might not have done the decoding yet, though.
Requiring that drawImage() become synchronous in certain cases seems suboptimal. Do other browser vendors have an opinion here? It's not really clear to me what the best solution is here. Obviously requiring that all images downloaded get decoded even if they're never used is a poor choice. Can we consider decoding images synchronously to be instantaneous, and thus make drawImage() do that safely? I guess, in the absence of requests to the contrary, that I will update complete to be defined in terms of having all the data immediately available, but not having checked whether the image can be decoded; I'll then clarify drawImage() and .height/.width to support the case of the image decoding happening on request and say how to handle errors in those cases.
In IE, load fires and complete is set to true when the download is complete and the the image is decoded. We don't carry out the decoding synchronously - making this sometimes synchronous doesn't seem like the best optimisation for web developers. We are investigating several optimisations in this area but all of them ensure that load and complete continue to mean the image is ready for immediate use.
Note that Gecko will discard decoded image data to reduce memory usage. So even if we waited until decoding completed to fire onload and set .complete to true, at some later point synchronous decoding might still be required. I'm not sure what the issue is with synchronous decoding per se; it's no different from the spec requiring that the behavior be as if the decoded data is always kept around, no? The one question in this bug is how to handle cases when decoding wouldn't happen at all normally wrt .complete and onload, right?
The only issue with synchronous decoding is that decoding can be slow, and we try to avoid baking in anything that might block the main thread doing something slow. However, I guess I could make the spec allow you to fire load/set complete after you've decoded if you wanted to, in which case UAs could pick either behaviour at will and there'd be no big problem here. So I'll do what I said in comment 5 but allow decoding before setting complete, at UA discretion.
(In reply to comment #7) > Note that Gecko will discard decoded image data to reduce memory usage. WebKit also does this (we do keep around the dimensions but not the pixel data).
Bake in in what sense? How is a UA throwing out the decoded image data and having to redecode on demand different from the UA serializing its DOM to disk to save memory (or heck, having it page out!) and having to read it in on-demand? Requiring synchronous decoding on drawImage if the data is not already decoded is the only reasonable course of action unless you want to add callbacks and significantly complicate the behavior of drawImage. The only question is whether it's ok to report the image as complete before all the pixel data has been decoded, right? Seems like the proposal in comment 8 should address that.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below. I revamped the <img> loading section to fix this and a number of other issues. Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r5639. Check-in comment: Revamp how <img> loading works. http://html5.org/tools/web-apps-tracker?from=5638&to=5639