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 _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
