- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 22 Nov 2010 16:04:48 -0800
- To: public-fx@w3.org
- CC: robert@ocallahan.org
- Message-ID: <4CEB0520.6020208@jumis.com>
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 UTC