This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15041 as part of operation convergence. Originally filed: 2011-12-02 11:25:00 +0000 Original reporter: John Knottenbelt <jknotten@chromium.org> ================================================================================ #0 John Knottenbelt 2011-12-02 11:25:10 +0000 -------------------------------------------------------------------------------- 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." ================================================================================ #1 Tab Atkins Jr. 2011-12-02 16:30:18 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #2 Simon Fraser 2011-12-02 19:15:50 +0000 -------------------------------------------------------------------------------- (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. ================================================================================ #3 Tab Atkins Jr. 2011-12-02 19:22:05 +0000 -------------------------------------------------------------------------------- But an image generated with 1 image pixel = 1 backing-store pixel will look double-size. So, we've gotta make some sacrifices somewhere. ================================================================================ #4 Simon Fraser 2011-12-02 19:23:20 +0000 -------------------------------------------------------------------------------- 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(). ================================================================================ #5 Tab Atkins Jr. 2011-12-02 19:27:15 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #6 Ian 'Hixie' Hickson 2012-05-03 16:48:16 +0000 -------------------------------------------------------------------------------- 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? ================================================================================ #7 Edward O'Connor 2012-05-03 17:08:14 +0000 -------------------------------------------------------------------------------- Sounds reasonable to me. ================================================================================
Done.