- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 23 Nov 2010 16:25:02 -0800
- 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 UTC