[whatwg] "canvas" tag and animations ?

[Charles Iliya Krempeaux]

Hello,

On 6/14/05, Dean Edwards <dean at edwards.name> wrote:
> Sjoerd Visscher wrote:
> > Charles Iliya Krempeaux wrote:
> >
> >> IMO, it would be better to a have solution to this built into the API.
> >>  Maybe with some kind of "drawing transaction".
> >>
> >> (A "draw transaction" is a little higher level than "double
> >> buffering", and allows you use other systems for this, other than
> >> "double buffering".  And would probably be safer, considering much of
> >> JavaScript is done via events.)
> >
> >
> > This isn't needed. Just like in normal HTML a drawing transaction is
> > automatically started when the javascript code starts, and finished when
> > the javascript code is done. And this is how it is implemented in
> > Firefox (don't know about Safari).
> >
> > Maybe the spec should describe this somewhere? Not specifically for
> > canvas, but for script in general: Changes on the DOM must be performed
> > instantly, and values like offsetWidth etc. must be recalculated, but
> > only visible when the script is done.
> >
> 
> What do you mean when you say "when the script is done" and "drawing
> transaction"?

Often, the first time people write a "graphics" application, they just
naively just draw everything to the screen.  The problem with is that
you can see everything being drawn.  (Every line.  Every polygon. 
Every texture.  Etc.)

This is no good.

What you need to do it display the entire frame all at once.  (The
user should NOT see you drawing the next frame.)

There is a technique call "double buffering" which solves this
problem.  It does this by having two "areas" -- by having 2 "buffers"
-- to draw frames.  One "buffer" is being shown to the user.  While
that is happening, the application draws the next frame to the hidden
"buffer".  When the application is done drawing the next frame (and
the time is right), it "switches" things.  The one that was "hidden"
is now the one being show to the user.  And the one that was
previously shown to the user, is now being used by the application to
draw the next frame.

But "double buffering" is not the only technique to solve this
problem.  So, to present an API that a in-different to the underlying
implementation, we give the idea of a  "drawing transaction".

I can go into more details if you want.  (Let me know.)

>From what I undestood (from what Sjoerd Visscher was saying), is that
there is no need for "drawing transactions" because of the way things
are done with JavaScript and the DOM.

A piece of JavaScript code only has a very short lifetime.  (There is
nothing like an event-loop or main-function with JavaScript.)  This is
because JavaScript code is only run in response to an event.  And if
you want things to "loop", then you need to do some tricks with
timers.

So, what would happen is that the results of your "drawing" would only
be shown after that piece of JavaScript code is finished executing.

(For the way things are now, this would seem to be sufficient.  But if
JavaScript coding ever allows for "long lasting" scripts to be run,
then this will become a problem.)


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/