On Tue, Nov 07, 2006 at 10:22:13AM +0100, Udo Giacomozzi wrote: > >> 1) Movie frame advancement, including updates to the general display > >> list, handling of events and processing of ActionScript > > s> NOTE: handling of user events (mouse move, key press, button press..) > s> is completely distinct from movie frame advancement. > s> They might or might not trigger re-rendering. > > That's right. I'd assign it to this point anyway.
I would NOT. "Movie frame advancement" is only for frame advancment. It would be the function to call at FPS intervals. Maybe you're thinking about a "Movie events handler" instead, I'd assign another number to it (we should be using a wiki for this job ..) See last thread on gnash-dev about invalidated bounds. This aspect is important to clarify. > >> We *can* improve the code so that also the offscreen buffer is only > >> updated where the player window is really visible. Of course in that > >> case re-rendering is required when the player window is uncovered (no > >> problem). > > s> Yes. > s> Expose event would call (2) [renderer] before doing (3) [refresh]. > s> Frame step or user event would call (2) [renderer]. > > Agreed. > > > s> The [renderer] itself will still call the Gui to know whether it's > s> really worth the rendering effort. > > That's not quite correct, as the GUI /requests/ the [renderer] to > calculate it's own invalidated bounds. However, these are just the > bounds that have /changed/ and nobody says these are the final > coordinates of the clipping area (let's give it a new name to avoid > confusion) while rendering. The latter is /told/ to the renderer and > can be completely different to the invalidated bounds. Or were you > referring to /your/ solution? I'm trying to define a good design togheter, not talking about the *current* implementation. I suggest we try moving this discussion to a wiki page. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
