W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2010

Re: Canvas in FX

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Nov 2010 16:25:02 -0800
Message-ID: <AANLkTi=i1M3Fd55ePeXgCXB-4Qw9z9rkgTJBsMC796Mc@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: public-fx@w3.org, robert@ocallahan.org
On Tue, Nov 23, 2010 at 4:12 PM, Charles Pritchard <chuck@jumis.com> wrote:
> There's a difference between using -element to make a dynamic background (or
> otherwise), and using it to fill a 'vector' element. We can use existing
> functions, with the existing canvas element, but I think it'd be wise to
> consider the "CSS Context" as an automated alternative.
>
> This is basically what I'm thinking of, as the typical case:
>
> // with a css transition applied to the canvas/parentNode on width changes.
> var increaseBy = 2;
> parentNode.style.width *= increaseBy; ctx.canvas.style.width *= increaseBy;
> ontransitionend = function() {
>  ctx.width = parseInt(parentNode.style.width);
>  ctx.scale(increaseBy,increaseBy);
>  myDrawCommands();
> }
>
> There are all sorts of tricky-techniques that could be used within that
> transition duration to make it more aesthetically pleasing. For instance,
> hooking into transitionstart instead of end, would mean that the image is
> not progressively blurrier during the transformation animation.

Are you suggesting that authors actually write the above code, or that
browsers do something magical that's equivalent to that code?


> Things get confusion/complex, if the canvas is assigned as a paint server to
> multiple elements having different sizes.
>
> For example: if the same paint server is assigned to a 20x20 area, and to a
> 1000x1000 area, it'd be faster [CPU cycles] to render to two different
> backing stores, than to size-down the 1000x1000 bitmap.

Possibly.  That depends on what's being drawn, and how efficient the
implementation is.  (For example, Chrome currently is much less
efficient at scaling <canvas> than <img>, but that's just a bug - we
cache scaled <img>s so we don't have to continually recompute, but we
don't do this for <canvas>.)


> Another issue, if we are toying with the bitmap backing, is considering
> ImageData/CanvasPixelArray performance. Because we're talking about the
> realm of SVG, generally, the user should be using SVG FE, and not ImageData.

Agreed that the author should be using SVG itself if possible, rather
than scripting at a canvas.  But scripting at a canvas is great when
you're trying to do something that doesn't have an existing
abstraction.

~TJ
Received on Wednesday, 24 November 2010 00:25:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 November 2010 00:25:56 GMT