Re: Canvas in FX

On 11/26/2010 8:25 AM, Simon Fraser wrote:
> 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.
I believe the proposal to be a managed-backing-store canvas. Not 
backing-store free.

You're free to correct me here: it's my understanding that painting 
calls happen within the event loop. Some implementations do run on a 
timing mechanism, whereby the screen is refreshed before the loop has 
ended. Those techniques may be fraught with problems, but they do 
reflect the current operation of existing implementations... so they 
can't be that bad. I would prefer that canvas  is not "repainted" onto 
the screen during an event loop, as repainting at any other time leads 
to undefined behavior (a partially drawn scene) hooked upon the speed of 
the host computer.

With this technique, the browser would not repaint using the new backing 
store until the end of the event loop, ensuring that JS is not doing 
anything to the store.
> 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.
I'm perfectly fine with that, as CSS does have the ability to resize the 
presentation, and those CSS calls are almost always triggered via the 
scripting environment.

I've worked quite a bit with Canvas and transforms and their intimate 
connection with CSS.
> * Canvas drawing is not callback-based, so:
>      i) there's no way to hook up a post-resize notification.
We've got onresize on window, we have transition events within CSS.

Canvas drawing is indeed callback based. It's hooked into window.onload 
events, and setTimeout, and run
during those associated event loops. It may be hooked to other events, 
but those are the primaries.

It's life inside of the event loop ensures that these things can run 
smoothly.

I've worked with the full dependency chain, with CSS and Window objects, 
I'm confident about its operation.

>     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).
This is something I'd like to see worked on. Currently, we just have to 
"guess", so we aim our setTimeout calls at about 25ms. It works when the 
browser can keep up. I'd much prefer to have some data from the browser. 
Moz is certainly on the right track. Microsoft went ahead and put 
"updateInterval" into the window.screen object. It's not a perfect 
solution, but it's an attempt at one. The Moz solution seems superior to 
me / more flexible. The MS solution is just simple.

http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 
<http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx>

> * Canvases are not high-DPI or transform-aware, so it's hard to get them to draw at the correct resolution.
This is only limited by the absence of DPI information being exposed in 
the scripting environment.
Canvas has had to be DPI-aware on mobile environments, with 
window.devicePixelRatio data.
It's drawing just fine in those situations.

I'd like to see additional metrics, on CSS pixels, exposed to the 
environment.

> CSS canvas solves none of these problems. I think if you want it to, we should solve them for HTML Canvas too.
I don't want to see HTML Canvas on a dynamic backing store. Doing so 
would confuse a low level API with a high level one.
I'm suggesting a CSS Canvas be treated as a more managed, high level API.

I believe I've addressed all of the issues you've brought up. Let me know.

-Charles

Received on Friday, 26 November 2010 17:17:08 UTC