W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2008

[whatwg] createImageData

From: Oliver Hunt <oliver@apple.com>
Date: Sat, 10 May 2008 19:38:00 -0700
Message-ID: <58FB08D0-F61E-45C3-A9DE-7AC789BE1154@apple.com>

On May 10, 2008, at 7:13 PM, Vladimir Vukicevic wrote:

> On May 10, 2008, at 5:44 PM, Oliver Hunt wrote:
>> On May 10, 2008, at 4:53 PM, Vladimir Vukicevic wrote:
>>> Another approach would be to not try to solve this in canvas at  
>>> all, and instead specify that by default, all canvas elements are  
>>> 96dpi, and provide authors a way to explicitly override this --  
>>> then using a combination of CSS Media Queries and other CSS, the  
>>> exact dpi desired could be specified.  (You can sort of do this  
>>> today, given that the canvas width/height attributes are in CSS  
>>> pixels, and that if CSS dimensions are present a canvas is scaled  
>>> like an image... so canvas { width: 100px; height: 100px; } ...  
>>> <canvas width="200" height="200"/> would give a 192dpi canvas  
>>> today, no?)
>> Canvas was designed with the intent of allowing resolution  
>> independent, removing that intent in the name of a feature that is  
>> not used in the general case seems to be a fairly substantial step  
>> back from that goal.  Unfortunately the "solution" of using a  
>> larger canvas scaled to fit a smaller region isn't a real  
>> solution.  For lower resolution displays it results in higher  
>> memory usage and greater computational cost than is otherwise  
>> necessary, and for high dpi displays it results either the same  
>> issues as the low dpi case (if the canvas resolution is still too  
>> high) or it results in a lower resolution display than the display  
>> is capable of.
> Eh?  The resolution used should be whatever the appropriate  
> resolution should be;  I'm certainly not suggesting that everyone  
> unilaterally create canvases with 2x pixel resolution, I'm saying  
> that the features exist to allow authors to (dynamically) create a  
> canvas at whatever the appropriate resolution is relative to CSS  
> resolution.
Ah, sorry for my misunderstanding. :-(

This still isn't ideal as it requires offloading such logic onto web  

>  Canvas was designed to allow for programmatic 2D rendering for web  
> content; resolution independence would certainly be nice, but it was  
> never a goal of the canvas spec.  In fact, the spec explicitly  
> states that the "canvas element represents a resolution-dependent  
> bitmap canvas".

Yes, in that once you draw to a canvas you can't just scale the canvas  
up and expect everything to remain crisp -- the only API's for which  
this is a problem are the ImageData ones.

>    - Vlad
Received on Saturday, 10 May 2008 19:38:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:02 UTC