gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] gui wants redraw


From: strk
Subject: Re: [Gnash-dev] gui wants redraw
Date: Fri, 8 Dec 2006 14:45:09 +0100

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;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]