[whatwg] Canvas size and double buffering.
Oliver Hunt
oliver at apple.com
Wed Feb 3 14:00:09 PST 2010
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/1e65c319/attachment-0002.htm>
More information about the whatwg
mailing list