[whatwg] Canvas size and double buffering.

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.

>> 2. Add an onresize event to the canvas tag. When the canvas is resized
>> it is reset and this event is fired.
> We actually need this for webgl as well.
>
>> 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!
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
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.

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.

Received on Wednesday, 3 February 2010 11:54:49 UTC