Re: Review of 3.14.11. The canvas element

Hello!

Le Fri, 01 Feb 2008 06:58:27 +0200, Ian Hickson <ian@hixie.ch> a écrit:

> On Tue, 21 Aug 2007, Mihai Sucan wrote:
>
> [...]
>
>> 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.
>
> I would imagine that most games would have to redraw everything anyway,
> since they likely want to keep everything centered, and will likely have
> HUD-like displays that will need repainting. Painting tools might benefit
> in certain cases (like when resizing the canvas means merely adding  
> pixels
> to the right and bottom), but not in others (like when resizing the  
> canvas
> means adding pixels to the left and bottom, or when scaling, etc).

Good points.


> In practice, it's easy to work around. Just create a new canvas using
> cloneNode(), drawImage() the first to the second, change your coordinate
> space units, and drawImage() the image back.

Sounds like a "hack" / a workaround.


>> 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.
>
> Done.

Thanks.


>> 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.
>
> Noted for v3.

Thanks.

>> 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.
>
> Sadly, this is not the case. I am already hearing browser vendors tell me
> they can't (won't) implement parts of the spec because they are concerned
> about compatibility with deployed content. Indeed, I have had to change a
> major part of the canvas spec (the way paths respond to transforms) in
> response to vendor feedback of this nature. So we can't change the method
> names now.

This sad, as you say, but it also feels "exaggerated". As in, everyone who  
uses such new technologies so soon, should be ready/prepared for changes.


>> 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.
>
> I think this should be already dealt with pretty well by getImageData().
> (We'll ba making some changes to make that even faster, too.)

Good to hear. Faster is always better.


>> 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.
>
> Agreed. There's a whole separate set of issues for that.
>
>    http://whatwg.org/issues/#graphics-canvas-text
>
> This will probably be done for v3.

Looking forward to this.

>> 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.
>
> Yeah, this is something we'll probably do in due course. There are a
> number of issues with exposing it to Web content though. For example, how
> to safely handle cross-domain content (e.g. with iframes present), how to
> handle rendering pages when the actual rendering has dimensions different
> than what the author expects, how to handle rendering nodes that aren't  
> in
> a DOM, etc. I imagine we'll revisit this for v3 or v4.

Good to know.

Thanks for your reply.


Best regards,

-- 
Mihai Sucan
http://www.robodesign.ro

Received on Friday, 1 February 2008 12:12:04 UTC