Review of 3.14.11. The canvas element

Hello!

I have reviewed 3.14.11. "The canvas element" section of the HTML 5  
specification [1], and I have the following suggestions and comments to  
make:


1. "Whenever the width and height attributes are set (whether to a new  
value or to the previous value), the bitmap and any associated contexts  
must be cleared back to their initial state and reinitialised with the  
newly specified coordinate space dimensions."

Why must the canvas image be cleared when the width/height changes?

Things as resizing the canvas are made harder, when one wants to keep the  
image.

Changing the width/height should be defined such that setting a higher  
value only adds transparent black pixels. For lower values, the image is  
truncated.

Applications like games and painting tools would benefit from not clearing  
the image when changing the canvas size. Games would only need to draw in  
the "new pixels". As defined, such applications would have to completely  
redraw the image on the canvas, making things slower.



2. There's a typo after the first code example (the one which shows how  
changing the width/height of the canvas clears the image):

"This specification only defines one context, with the name "2d". If  
getContext() is called with that exact string for *tis* contextId  
argument, then the UA must return a reference to an object implementing  
CanvasRenderingContext2D. Other specifications may define their own  
contexts, which would return different objects."

Correction: tis = this.



3. The getContext() method should be defined such that any number of  
additional arguments are allowed, just like toDataURL() is defined. This  
is forward thinking about initializing various contexts with any settings.

For example, implementations may allow for initializing a 3d context with  
software rendering, or hardware rendering, as needed by the application.

This could, theoretically, be dealt with by having additional  
methods/properties on the returned context. For example:  
getContext("3d").renderMode = 'sw'|'hw'. However, technically, I think an  
implementation would need to initialize the rendering with the given  
renderer. Today's games cannot change the renderer while running, only  
after restart. Therefore, maybe there's a need for getContext() allowing  
any number of arguments.



4. In the 3.14.11.1.10. "Pixel manipulation" section [2] one can read:

"The data returned by getImageData() is at the resolution of the canvas  
backing store, which is likely to not be one device pixel to each CSS  
pixel if the display used is a high resolution display. Thus, while one  
could create an ImageData object, one would *net* necessarily know what  
resolution the canvas expected (how many pixels the canvas wants to paint  
over one coordinate space unit pixel)."

This is the first paragraph found in the provded example.

Correction: one would need to know what...



5. Drawing states should be saveable with IDs, and for easier restoring.

save(id)
restore(id)

If id is not provided, then save() works as defined now. The same for  
restore().

Currently, it's not trivial to save and restore a specific state.



6. I do not "like" the save/restore() method names.

It's ambiguous what they do. I initially believed they do what's suggested  
in the next point.

I would suggest renaming the methods to: saveState() and restoreState().

I don't believe it can be argued that such changes break (too many)  
applications. Today's applications using canvas are experiments. The  
entire spec is subject to change, and as such nobody should complain.



7. On the basis of save()/restore() state, I think it would be a good idea  
(performance-wise, for various applications), to be able to do something  
like this:

saveImage(id)
restoreImage(id)

This wold allow caching images drawn by the application, in the memory  
provided by the UA. Currently, one could use a data URI, or an ImageData  
object, but such solutions are far from ideal since they are not as fast  
as native UA methods, plus they use more memory than a native  
implementation.

The saveImage and restoreImage methods could also allow four optional  
arguments: x, y, w and h. Obviously, these define where to start from and  
where to end saving/restoring the image.



8. I would add my "two cents" about providing a way to render text, but  
this has already been over-discussed. Yes, something that would be needed.



9. I would propose something different, a different idea. Why not define  
an optional method for the 2d context, which allows authors to say  
something like importNodeRender()? Here's the "funky" idea:

importNodeRender(node)

... where node is any DOM node, e.g. document.getElementById('whatever').  
The way "captures" the rendered image of that element, irrespective what  
it is (maybe it's SVG, Flash, simple HTML+CSS, whatever).

importDocument(x, y, w, h)

This method could allow the author to capture a part of the rendered  
document page. x and y positions are taken from the entire document, not  
just the visible page, in the current window size.

This capability would allow authors to "hack" a way to render text in the  
canvas view. Of course, this would allow much more than that.

Would this be overly complex? Popular UAs already have ways to generate  
page thumbs.




[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#the-canvas
[2]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#pixel



-- 
http://www.robodesign.ro

Received on Tuesday, 21 August 2007 16:08:51 UTC