Re: Canvas in FX

On Nov 23, 2010, at 6:42 pm, Charles Pritchard wrote:

> On 11/23/10 5:46 PM, Tab Atkins Jr. wrote:
>> On Tue, Nov 23, 2010 at 5:32 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>>   
>>> I'm suggesting that browsers do some magic for "CSS Canvas";
>>> I'm stating that authors will/do actually write that code when the use case
>>> requires it, with HTML Canvas.
>>>     
>> I don't understand what the distinction is supposed to be between a
>> "CSS Canvas" and an "HTML Canvas".
>> 
>>   
> Understood. I'm trying to create one (a distinction).
> 
> HTML Canvas is the current canvas element.
> 
> CSS Canvas is a new construct, based on the idea of a Canvas intended for use as a paint server.
> 
> HTML Canvas has two sets of dimensions: [canvas width="100" height="100" style="width: 100px; height: 100px"].
> CSS Canvas has only one set: getCSSCanvasContext('2d', id, '100', '100) ;
> 
> CSS Canvas use cases are based on the concept of an wider scene graph. HTML Canvas may be used independently.
> 
> And boiling it down: CSS Canvas could (should?) operate with a dynamic backing store,
> the backing store of HTML Canvas is, and should remain static.
> 
> CSS Canvas could even have multiple backing stores, of different dimensions, to speed up rendering,
> as the paint service may be used multiple times in a document, at different scales.
> 
> In some part, CSS Canvas is a more high-level abstraction than HTML Canvas.
> 
> You can't pry HTML Canvas out of my cold dead fingers. That being the case, I wouldn't mind having a 'managed' CSS Canvas element, from the CSS world.
> 
> I actually do a lot of management of HTML Canvas with CSS, via z-index, clipping, width/height/positioning, display/visibility,opacity.


First, what you are asking for is a backing-store-free canvas, where your JS gets some callback as the browser is painting, and you can use the canvas API to paint gradients etc. into the same graphics context that is being used for the rest of its rendering. This might seem tempting, but it's fraught with problems. First, being able to run arbitrary JS during the painting phase is extremely dangerous; you can modify the DOM (and hence the rendering tree) while the painting code is traversing it, which the browser would have to disallow somehow. The alternative is to have all the canvas painting happen first, but then you end up back using backing store. Second, if indeed the JS is allowed to do painting while the browser is also painting, it would be possible for the JS to leave the graphics context in a bad state, killing all subsequent drawing. This approach just has too many problems.

So that leaves us with the backing-store canvases.

HTML Canvas certainly has a number of serious failings:
* The backing store is a fixed size, and there's no way for JS to dynamically resize it when the presentation size of the canvas changes because of layout or transforms.

* Canvas drawing is not callback-based, so:
    i) there's no way to hook up a post-resize notification.
   ii) canvases can't hook into the browser's drawing cycle, so they often end up doing far more animation and drawing than is necessary (this is one thing that mozStartAnimation() aims to solve).

* Canvases are not high-DPI or transform-aware, so it's hard to get them to draw at the correct resolution.

CSS canvas solves none of these problems. I think if you want it to, we should solve them for HTML Canvas too.

Simon

Received on Friday, 26 November 2010 16:26:28 UTC