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

Canvas in FX

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 22 Nov 2010 16:04:48 -0800
Message-ID: <4CEB0520.6020208@jumis.com>
To: public-fx@w3.org
CC: robert@ocallahan.org
Hello FX list.

Some time, long ago, Doug expressed interest in developing SVG to better 
use the HTML [canvas] tag. Recently on the WHATWG mailing list, Robert 
O'Callahan shared an idea for Canvas, to help with resolution 
independence, and I think it fits nicely as an SVG+CSS Canvas note. I 
want to stress, that getContext and getCSSCanvasContext are and should 
remain two separate APIs, as they have differing semantics.

WebKit introduced getCSSCanvasContext quite some time ago:
http://webkit.org/blog/176/css-canvas-drawing/

Robert's proposal would make reasonable sense for a CSSCanvasContext, 
and could work especially well when a canvas object is used inside of an 
SVG graph, provided  canvas is apprised of scale re-size events of its 
parent group.

This is intended strictly for CSSCanvas, even though I'm using the 
HTMLCanvas tag:

<svg><g style="scale(1.5, 1.5)"><canvas></canvas></g></svg>

Tweaking Robert's proposal, the canvas backing store would be scaled by 
1.5 times, so that, when displayed, it matches the same resolution as 
the <g>.

I realize this is my first post on the list, and I haven't fully 
explained the use case. But I thought I'd start somewhere.

The canvas backing store is a bitmap. That's how it works. That backing 
store size could be dynamically increased and decreased, to best match 
the css resolution of its containing group.

Integrating that trick into SVG+CSS Canvas would make it easier for 
authors to use Canvas within an SVG document, keeping the bitmap 
resolution in line with the SVG resolution, and optimizing for a smaller 
resolution when the containing element is indeed smaller.


The following is Robert's proposal, which prompted my e-mail to this list:
(I've heavily borrowed from it, my proposal to this list is quite 
different than the original, but in the same spirit).

On 11/22/2010 12:30 AM, Robert O'Callahan wrote:
> So, for example, I wouldn't want to add canvas features to address 
> use-cases for which SVG would work well if it was a bit better 
> implemented.
>
>
>>     I understand the need to make canvas backing store pixels map to
>>     device pixels when possible. Suppose that, on clearing the canvas
>>     (e.g. by setting the width or height attribute), the browser
>>     automatically set the canvas backing store density so that canvas
>>     backing store pixels map to device pixels (taking into account
>>     the current zoom settings). Suppose further that browsers fired
>>     the 'resize' event when they zoom in a way that changes the
>>     window size (as they should, even if they currently don't). Then
>>     on 'resize' you could clear your canvas and redraw it, and
>>     automatically get a canvas backing store with the right
>>     resolution with no further code changes. Would that address your
>>     use case?
>
>
Received on Tuesday, 23 November 2010 00:04:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 November 2010 00:04:40 GMT