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.
Moreover using a larger canvas than necessary will result in much higher memory usage for engines like WebKit which do support high DPI displays, and so will end up with a scaled high resolution canvas.
--Oliver
