[whatwg] Canvas suggestions

[Jordan OSETE]

Maciej Stachowiak wrote :

> One reason the API works this way is that in the CoreGraphics drawing 
API on
> 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 
some systems?
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.

Ie:
ctx.fillStyle = [];		//sets the global internal colorsAsArray flag 
without changing the fill-color value
alert( ctx.strokeStyle.length );//should display 4
ctx.fillStyle[4] = 0.5;		//only affect transparency
ctx.strokeStyle = '';		//clears flag colorsAsArray without changing the 
value
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 3.14.11.1.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
 > respect.

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:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-October/007363.html
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 
apparent reason...

 > Best regards,
 > Stefan Haustein

 > Regards,
 > Maciej

Thank you for answering :)
Regards.
Jordan Osete