[whatwg] "canvas" tag and animations ?

Charles Iliya Krempeaux supercanadian at gmail.com
Wed Jun 15 11:00:46 PDT 2005


On 6/15/05, Dean Edwards <dean at edwards.name> wrote:
> Sjoerd Visscher wrote:
> >
> > They are applied immediately (internally in some kind of buffer), but
> > not visible.
> >
> > About "when script is done", most cases are easy. But as always with
> > HTML there are hard edge cases.
> >
> > Script from a script block is done when the last statement in that block
> > has been executed. The same goes for onevent attributes.
> >
> > Another possibility is calling a script function from an internal event,
> > like what happens with setTimeout or addEventHandler. Then the script is
> > done when the function has been executed. I'm not sure what happens when
> > there are more event handlers for the same event.
> >
> > (I'll leave aside what this means for expression() in CSS in IE)
> >
> Where does it say all this in the spec?
> Surely, the canvas element is updated every time a drawing method is
> called. End of story.

Well, we need to decide on one or the other, and make it explicitly
"spelled out" in the spec.

(And if drawing operations are done and shown immediately, then it
would be desirable to have "drawing transactions".)

To be honest, the think the idea of "drawing transactions" is better. 
Here are the reasons:

#1: It makes it so, if the develop wants it, that they can have things
that are "drawn" show up immediately.  (I.e., they aren't forced to
use "double buffering" [or whatever].)

#2: It makes it so you could have "long lasting" scripts execute.

#3: It makes it so Java and C++ interfacing will work the same. 
(I.e., you don't have to give C++ and Java an API to effectively do
"drawing transactions" without also giving this API to JavaScript.)

So +1 for "drawing transactions" :-)

See ya

     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com

     developer weblog: http://ChangeLog.ca/
 Ask the toughest Linux System questions at...   http://linuxmanagers.org/

More information about the whatwg mailing list