Re[2]: [Gnash-commit] gnash/gui gui.cpp gui.h

[Udo Giacomozzi]

Hello strk,

Friday, November 3, 2006, 11:10:10 PM, you wrote:
s> mmm... I don't like GUI events to be driven by frame rate.

Agree.

s> I think movie events should be handled like user event (ie: when
s> they happen). Colin Moock in his book refers to event as divided
s> in "user" or "system" events.
s> System events include 'enterFrame'. I guess we might add 'window expose'.

s> Consider a movie at very low frame rate, do we really want to wait
s> for next frame before redrawing a just-raised window ?

No, but I'd not redraw for each event either. Instead, somewhere in
between, like when all events have been handled, which does not
necessarily mean that resizing ended. I mean, redraw as fast as
possible but skip a resize event when there is already another one
waiting. Don't know if GTK has somewhat like a event queue, though.

s> Yes, each Gui might implement this internally, but what would the
s> point be for the above _redraw_flag then ?

My intention was to rescale the buffer with each resize event (which
sets the flag) and as soon the application is "idle" redraw the
buffer. This "idle" could be a one-shot timer triggering the real
redraw at a limited rate.

Anyway, the current design let's the decision up to the GUI when it
should render again...

What's missing is a GUI function that does immediate redrawing. The
flag is something like a fallback flag when the individual GUI does
not trigger a redraw itself.

Udo