This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems suggested, but not explicitly stated, that the dimensions of the image produced by toDataURL will match that of the underlying image data, as returned by context.getImageData(). The dimensions of the produced image will, therefore, not necessarily be the same as width and height properties of the canvas. It would be great to clarify this point in the spec. Below are some related paragraphs in the spec: 4.8.11.1 "The toDataURL() method must not include color space information in the resource returned. Where the output format allows it, the color of pixels in resources created by toDataURL() must match those returned by the getImageData() method." ... "Thus, in the 2D context, calling the drawImage() method to render the output of the toDataURL() method to the canvas, given the appropriate dimensions, has no visible effect."
I disagree that toDataURL should have the same behavior as getImageData here. getImageData is sensitive to the backing-store resolution, and importantly, will correctly round-trip an image. toDataURL should be producing an image identical to what's displayed in the canvas. If it produces an image with one image pixel = one backing store pixel, then it won't roundtrip through canvas, which your spec quote implies should happen. toDataURL, thus, should use screen pixels, not backing store pixels. If an output format support sub-pixel information, then sure, include it. But for formats like JPEG and PNG, it shouldn't.
(In reply to comment #1) > toDataURL should be producing an image identical to what's displayed in the > canvas. If it produces an image with one image pixel = one backing store > pixel, then it won't roundtrip through canvas, which your spec quote implies > should happen. > > toDataURL, thus, should use screen pixels, not backing store pixels. These two statements are not logically consistent. If the canvas has 2x backing store, but toDataURL uses screen pixels, then the toDataURL image will look fuzzy compared to the canvas on a 2x display.
(In reply to comment #2) > (In reply to comment #1) > > > toDataURL should be producing an image identical to what's displayed in the > > canvas. If it produces an image with one image pixel = one backing store > > pixel, then it won't roundtrip through canvas, which your spec quote implies > > should happen. > > > > toDataURL, thus, should use screen pixels, not backing store pixels. > > These two statements are not logically consistent. If the canvas has 2x backing > store, but toDataURL uses screen pixels, then the toDataURL image will look > fuzzy compared to the canvas on a 2x display. But an image generated with 1 image pixel = 1 backing-store pixel will look double-size. So, we've gotta make some sacrifices somewhere.
(In reply to comment #3) > But an image generated with 1 image pixel = 1 backing-store pixel will look > double-size. > > So, we've gotta make some sacrifices somewhere. Right. So do you make things lossy but work for naive web developers, or non-lossy but require a bit more web author smarts? We went the latter route for getImageData().
(In reply to comment #4) > (In reply to comment #3) > > But an image generated with 1 image pixel = 1 backing-store pixel will look > > double-size. > > > > So, we've gotta make some sacrifices somewhere. > > Right. So do you make things lossy but work for naive web developers, or > non-lossy but require a bit more web author smarts? We went the latter route > for getImageData(). Yes, and I think that was the right choice - when you're pulling out the image data explicitly, you generally actually want the real data. However, there's no way to express the dpi of an image in a way that a web browser will automatically pay attention to, unfortunately.
We're likely to add an HD version of getImageData() that's defined as the current one is and redefine the current one to use CSS pixel resolution, so maybe we should do the same with toDataURL and have a toDataURLHD?
Sounds reasonable to me.
This bug was cloned to create bug 17978 as part of operation convergence.
Moved to canvas component.
This is a new feature. Moving it to HTML.next This is also not part of the canvas 2D spec. Moving it to HTML
Mass move to "HTML WG"
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: None (already in the spec) Rationale: Since the filing of this bug, the W3C spec has incorporated the toDataURL, toDataURLHD, getImageData, and getImageDataHD definitions and clarifying text from the WHATWG spec: https://github.com/w3c/html/commit/857a787b304e602a1cb2fea21b6dbfcb29107a09