[whatwg] "canvas" tag and animations ?
Charles Iliya Krempeaux
supercanadian at gmail.com
Tue Jun 14 13:48:18 PDT 2005
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
> > This isn't needed. Just like in normal HTML a drawing transaction is
> > 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
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
you want things to "loop", then you need to do some tricks with
So, what would happen is that the results of your "drawing" would only
(For the way things are now, this would seem to be sufficient. But if
then this will become a problem.)
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