- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Tue, 21 Aug 2007 19:08:26 +0300
- To: public-html <public-html@w3.org>
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