[whatwg] Canvas suggestions

[Maciej Stachowiak]

On Apr 15, 2007, at 11:15 AM, Jordan OSETE wrote:

> Hello folks at the WHATWG.
> Some simple suggestions about the great <canvas> tag:
>
>
> Clipping-paths:
> ---------------
> Right now if i understand it correctly, the clip() function creates  
> a new clipping path, being the intersection of the last clipping path.
> I have not seen any way to actually come back to a full clipping  
> path, apart from calling restore() if you have saved it before,  
> wich forces to save the clipping path each time you want to modify it.
> Also we can only intersect it, but not substract it or add anything  
> to the current clipping path, wich are usual cliping path  
> operations in drawing software.
>
> A way to fix both would be to have some kind of property of the  
> 2Dcontext object to select the operation (like  
> globalCompositeOperation for painting). Operations like "add",  
> "substract", "replace", "intersect" and "xor" come to mind  
> (defaulting to "intersect").

I think you would want different methods for these if you had them.  
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

> Save-restore:
> -------------
> Instead of having a last-in-first-out-like save-restore mecanism,  
> why not return an object with save() that could be restored with  
> restore(obj)?
> Maybe changing the names of the methods to keep it backward  
> compatible.
> This would give much additionnal flexibility.
>
> Also, maybe saving everything at once is not always needed.  
> Independant save/restore methods for clipping paths, actual paths,  
> transformations, stroke/fill styles and shadows (have i forgotten  
> something?) would be even more versatile, and allow for better  
> performance sometimes (saving only what is needed).

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.

> Color / style:
> --------------
> Reading colors can be complex. Right now it returns a string either  
> in the form #xxxxxx or rgba(...), depending on the alpha value. It  
> means the reader must be able to parse both, because he never knows  
> if the color's alpha is 255 or less. Maybe always returning rgba()  
> would be easier to parse? Or a second property wich would return an  
> array of the integer/float RGBA values when read?

Changing the property would be a compatibility risk, but

>
> Path API:
> ---------
> Currently, there are only ways to _set_ the last point of a subpath  
> (through any of the xxxxTo() commands), but not to read it. Since  
> it must be kept in the UA's memory anyway, why not have a  
> getLastPoint() function? If not, it forces the user to keep himself  
> track of the last point (or (s)he needs to override all of the  
> xxxxTo functions to do that "transparently").

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.

> Less important, but probably easy to implement as well: relative  
> xxxxTo commands. I mean relative to the last point. Maybe new  
> functions like moveToRel/lineToRel/etc., or a context property  
> "pathBase" to set the base for path API moves ("absolute" and  
> "relative"). The latter would avoid creating thousands of functions  
> (especially if another kind of coordinates must be added in the  
> future).

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.

Regards,
Maciej