[whatwg] Canvas suggestions
jordan.osete at laposte.net
Mon Apr 16 13:46:57 PDT 2007
Maciej Stachowiak wrote :
> One reason the API works this way is that in the CoreGraphics drawing
> the Mac, there's no way to add anything to the clip region directly, so
> it would be necessary to track all the context state manually and union
> paths to support these operations. The
Didn't know that. Being able to do other operations with clipping paths
would be useful, though. Wouldn't there a way to implement it in the UAs
itself for these cases, even if there is a slight loss of performance on
Unfortunately if we want to do another operation that is not native,
only the UA can implement it, not the web application.
If that is not possible, a way to reset the clipping path to full
without having to call save/restore would still be appreciated.
> Many graphics APIs (including CoreGraphics) have a built-in LIFO model
> for save/restore, so it's likely to actually lead to worse performance
> to support fine-grained save/restore on such systems.
Hm, unfortunate. Well, if there is a way to restore to a full clipping
path without that, it is less important for me.
> Changing the [color] property would be a compatibility risk, but
In that case, we could detect if the application tries to set an array
to the properties fillStyle or strokeStyle, and if it is the case, then
it means that the given application is more recent than the change from
string to array, and we can switch to an array-like reading.
An internal "colorsAsArray" flag could then be set, and any reading from
any color property would after that return an array.
Maybe let the possibility to switch back to the original behaviour by
setting to a string?
Note that setting any color to a zero-length array should not modify the
property itself, but still set the internal "colorsAsArray" flag.
ctx.fillStyle = ; //sets the global internal colorsAsArray flag
without changing the fill-color value
alert( ctx.strokeStyle.length );//should display 4
ctx.fillStyle = 0.5; //only affect transparency
ctx.strokeStyle = ''; //clears flag colorsAsArray without changing the
alert( ctx.strokeStyle ); //displays either a "#xxxxxx" or a "rgba(...)"
string depending on the alpha value
> If we wanted to have more introspection of paths, I think it would make
> sense to have a path object and let you get one for the current path.
Indeed, it would be the best way, though retrieving the last point would
still be handy, and probably simpler to implement ;)
If this is accepted, a "getLastAngle" would be useful as well, wich
would return the angle of the tangeant to the last path component drawn,
at the last point. The browser already knows how to calculate that (it
has to know because of line joins and miter limit).
Maciej Stachowiak wrote:
> You can achieve relative moves by doing a translation to the current
> point when drawing; this is a more general version of what your
> pathBase property would do.
It would indeed be more the best way, allowing full transformations
while drawing. See the next point.
Stefan Haustein wrote:
>the WHATWG spec says you cannot do so (section 184.108.40.206.8):
>"Note: The transformation is applied to the path when it is drawn, not
> when the path is constructed. Thus, a single path can be constructed
> and then drawn according to different transformations without
> recreating the path."
> BTW: The Mozilla Developer Connection clock sample relies on applying
> transformations at construction time, but runs fine in Firefox 2, so
> at least the Firefox implementation seems to be non-conforming in this
Yes, but there are complex shapes that can be made really easier to draw
this way. On the other hand, the way the current specification works
allows to construct a single shape once, and draw it in different ways
around, by just modifying the transform attribute...
It would be nice to have both, being able to use transformations
independantly for drawing and constructing the path.
I don't know if it would be very hard to implement or not? (well,
obviously not for the mozilla project, since they already have it ;)
Anyway, now that you mention it, we really need a way to retrieve the
current transform matrix. Like the current point, it is something that
already is in the browser's memory, so a function returning an array
would be enough.
> In my opinion, relative moves easily become confusing in the case of
> Bezier Curves (what is the point of reference for the third and fourth
> coordinate pair?), and additional methods would basically be redundant
> without significant gains in functionality or speed.
Hm, i think i can agree. As mentionned before, transformations would be
more versatile for this purpose, and the whole 3*3 matrix is used
everywhere, so it is well known. If we can have a mecanism affecting the
path when it is constructed, transformations would probably be better.
> BTW2: What about drawString(), I'd really love to see this one...
Again, i can only agree. I read most of the subject:
and it seems it is one of the most wanted features (just like font
downloading for the "usual" web). It seems the concerns where mostly
technical, but the discussion stops in the middle of it, with no
> Best regards,
> Stefan Haustein
Thank you for answering :)
More information about the whatwg