[whatwg] Canvas size and double buffering.

On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:

> On 3 February 2010 19:23, Oliver Hunt <oliver at apple.com> wrote:
>>> 1. Support more length specifiers for the width and height of a
>>> canvas(%, em, etc.).
>> 
>> This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel.
> 
> The layout engine would decide how many pixels big it is, in exactly
> the same way that it decides how big to draw a image that has width
> specified in non-pixel units.

But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. 
>> 
>>> 3. CSS size specifiers resize rather than scale the canvas. I.e. it
>>> should always be that 1 unit = 1 pixel initially.
>> This would break content
> 
> On 3 February 2010 18:07, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> #3 would break existing canvas content.
> 
> True, but:
> 
> a) Otherwise width:100% in CSS and width="100%" in HTML would have
> different meanings. Confusing!

width="100%" makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based.

> b) Nobody uses it currently anyway - there's no content to break! I'm
> not exaggerating - look through canvasdemos.com and I bet you won't

Because canvasdemos.com is the only site in the world that uses canvas.

> find a single case where the canvas is sized using CSS, for the very
> reasons I have given, specifically:
> c) It's slow, and looks rubbish.
This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image.

> 
> I suppose an alternative might be to have some way of retrieving the
> true size of the canvas, then you could do something like:
> 
>    canvas.width = canvas.trueWidthInPixels;
> 
>> #2 would work if all elements supported onresize (as has been proposed),
>> right?
>> 
>> Given that, a resize handler could simply reset the canvas width/height
>> attrs if desired (thereby achieving #1 and the clearing aspect of #2), no?
>> 
>> Hence my question: what use cases here would not be covered simply by having
>> a general resize event on all elements?
> 
> Well, yes it would be good to have onresize for all elements. But you
> still need to add width="...%" support to the canvas tag otherwise it
> will never *be* resized, so you couldn't achieve #1 with #2. I may
> have misunderstood you here.

The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution.

--Oliver


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100203/0a578f94/attachment.htm>

Received on Wednesday, 3 February 2010 12:11:43 UTC