[whatwg] Canvas comments

On Tue, 25 Dec 2007, Ilmari Heikkinen wrote:
> 
> Some comments on the canvas spec, based on my experiences in writing a 
> SVG renderer and some interaction demos on canvas 
> (http://glimr.rubyforge.org/cake/canvas.html)

Cool stuff.

> I would change the transforms to affect only path segments, fills and 
> strokes done _after_ the transform. Currently, Firefox and Safari apply 
> transforms that way, but Opera's transforms also affect the points 
> created before the transform.
> 
> This would make path construction easier and would also make it possible 
> to emulate pattern-space transforms (to some degree) by applying 
> transforms after the path creation, but before fill / stroke. Though, it 
> doesn't quite work, as the transform affects the stroke width as well...

Already done.


> ...so there is a need for pattern space transformations. Which would be 
> a transformation matrix applied after creating the stroke/fill geometry, 
> but before filling in the pattern/gradient. The pattern space transform 
> matrix should be a property of the pattern object, and the pattern 
> object could also have #translate, #rotate, #scale, #transform and 
> #setTransform.

You can do that now by rendering your pattern with a transformation to 
another canvas, and then using that canvas as the pattern for your actual 
target canvas.


> The wording in isPointInPath is confusing. Are isPointInPath coordinates 
> user-space coordinates or device-space coordinates? Are they coordinates 
> transformed by the CSS transformation matrix for the canvas tag?
> 
> E.g. if there's a one-pixel size square at 10,10 on the canvas, does 
> isPointInPath(10,10) return true for it? What if the canvas is CSS 
> scaled to 200% size? How do you find out the CSS matrix?

The new text should make this clearer -- let me know if it's still vague.


> There's no getTransform(). I'd go with 
> ctx.setTransform(ctx.getTransform()) being a no-op, and there being a 
> way to get the transformation matrix for the canvas surface as well 
> (i.e. the CSS transformation matrix for the canvas.)

My understanding is that it's not always possible for implementations to 
actually obtain the transformation matrix easily (short of caching it 
independently of their rendering subsystem).


> The goal here being the ability to map mouse coordinates to user-space 
> and back, along with the ability to align HTML elements and canvas 
> objects.

Actually for that kind of thing I'd recommend SVG -- media-specific 
rendering (e.g. aligning markup with canvases or images) is specifically a 
non-goal for HTML5.


> Canvas features needed by the SVG renderer:

An SVG renderer is definitely a non-goal for <canvas>. Just use SVG. :-)


> * A text API with: CSS style object as ctx.style (not string), text as path,
>   text along path [as path], font metrics, text selection path with text
>   bbox rectangles (for use with isPointInPath.)

Text APIs will be handled at some future point. See:

   http://whatwg.org/issues/#graphics-canvas-text

If you don't see your specific needs covered by those e-mails, please send 
additional feedback.


> [a variety of feature requests]

There are indeed a large number of features that could be added. At this 
stage, we should focus on getting interoperability on the existing 
featureset. If there are specific features that you would need for 
specific purposes (e.g. people have asked for dashed lines for diagrams, 
and for text for chart labels) then please do suggest them (along with the 
use cases and examples of why it's impossible or at least very hard to do 
without the feature), so I can add them to the v3 feature list.


> (And views on what Canvas text will be used for:
> 
>  * Spiffying up HTML titles and leaving the HTML element above the canvas at
>    zero opacity == selectable spiffy text. Requires exact HTML element
>    rendering on Canvas.
>  * Text art. Needs text-as-path and text-along-path.
>  * Titles for canvas elements. Needs a way to align text vertically and
>    horizontally (== font metrics and string dimensions.)
>  * Writing a SVG renderer with selectable text. Needs text-as-path and
>    text-along-path, and a fast text picking path.)

None of those are really the intended use cases for <canvas>. :-)

Indeed for most of those, I would recommend using SVG, possibly, in the 
future, with XBL.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 31 January 2008 22:23:03 UTC