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. 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".
- Vlad
