[whatwg] Canvas comments

Ilmari Heikkinen ilmari.heikkinen at gmail.com
Tue Dec 25 13:59:14 PST 2007


Hi,

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)

1.
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...

2.
...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.

3.
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?

4.
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.)

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.



Canvas features needed by the SVG renderer:

* 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.)

* Any way to do masking? That is, have an image used as an alpha multiplier.

* SVG filters

* Gradients and patterns sized to object bbox.

* Dashed strokes

* Easy way to draw markers (needs location and tangent angle of a point on
  the path.)

* Path lengths (I think?)


And now for some random comments and feature requests:

* Repeating gradients would be nice to have. And conical gradients.
  And mirrored gradients.

* A larger variety of blendmodes, see e.g.
  http://www.pegtop.net/delphi/articles/blendmodes/index.htm

* There's no fast way to edit the pixels on the canvas.
  putImageData and getImageData are glacial, as is fillStyle= + fillRect().
  Byte arrays (well, if strings were bags of bytes, they'd work too) or a
  shader language, maybe? I don't know.

  Python and Ruby have to deal with similar dynamic typing overheads, so
  their libraries may have solutions applicable to JavaScript, e.g.
  http://www.pythonware.com/library/pil/handbook/index.htm
  Also see comments in http://bel.fi/~alankila/plasma.html

* The globalCompositeOperations "lighter" and "darker" are too easily confused
  with "lighten" and "darken", which have a completely different effect.
  I think they're usually called "add" and "subtract".

* isPointInStroke

* drawElement for drawing HTML elements


(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.)



Whew, that got a bit long, hope I didn't bore you to death.
--
Ilmari Heikkinen
ilmari.heikkinen at gmail.com



More information about the whatwg mailing list