Re: [Gnash-dev] gui wants redraw

[strk]

On Tue, Nov 07, 2006 at 12:36:18AM +0100, Udo Giacomozzi wrote:
> Hello strk,
> 
> Monday, November 6, 2006, 11:13:48 PM, you wrote:
> s> mmm.. let's try to summarize.
> 
> I like summaries, but I have difficulties to understand your post. In
> particular I don't understand why you distinguish between on-screen
> and off-screen rendering.

I probably just used a wrong term, my point (3) [offscreen->onscreen]
should not be described using the 'rendering' term, I see you
calling 'blitting', but I don't know exact definition so I'm not
sure it's appropriate. Basically (3) would NOT involve any render_handler,
but just onscreen refresh.

> Probably my head is full of too much things, too ;)
> 
> Let me try to describe my point of view...
> 
> I see two major functionalities (does not necessarily have to be a
> /replacement/ for your definition):
> 
> 1) Movie frame advancement, including updates to the general display
> list, handling of events and processing of ActionScript

NOTE: handling of user events (mouse move, key press, button press..)
      is completely distinct from movie frame advancement.
      They might or might not trigger re-rendering.


> 2) Rendering of the current movie state, which is just a visual thing
> and does not change the movie state in any way
> 
> Both parts are independent in some way, meaning that you can advance
> 10 frames before rendering one if you wish without problems. Or, you
> can re-render the same frame multiple times which will always result
> into a identical visual presentation.

Agreed.

> Reasons for advancing frames without rendering them:
> - to keep in sync with the frame rate on slow computers (skip frames,
> not what the original Flash plugin does, but that's "just" a
> compatibility question)
> - the player window is covered completely or minimized
> - there is no player window at all
> 
> Reasons for re-rendering frames without advancing:
> - A part of the player window has been uncovered and the image
> underneath is not available as a buffer
> - The player window has been resized and immediate re-rendering is
> required
> 
> Both reason lists are independent from each other which explains why I
> would divide advance_movie() from display().

Agreed.

> Now, at least the GTK-AGG combination *currently* always renders into
> an offscreen buffer. This means that when uncovered, re-rendering is
> *not* necessary as all info is ready in the offscreen buffer and just
> needs to be blitted again. Same applies for the FB GUI.

That's why I also define (3), it exists as a funcional unit.

> Can't tell how OpenGL works but I guess it also uses some sort of
> offscreen buffer to avoid flicker.
> 
> 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).

Yes.
Expose event would call (2) [renderer] before doing (3) [refresh].
Frame step or user event would call (2) [renderer].
The [renderer] itself will still call the Gui to know whether it's
really worth the rendering effort.
So (I know see the odd flow you were seing in a previous mail)
when expose window event is triggered we'd have a little chat:

  - gtk calls [renderer] (to ensure rendering before refresh)
  - [renderer] calls gtk (to know whether it is really worth to render)

> This makes particularity sense for the web browser plugin
> to avoid cpu-intensive rendering of parts of the page that are not
> visible in the current scroll window (just think about skyscraper
> format ads).

Indeed.

> To make things even more complicated I add two thoughts (past-0.7.2):
> :D
> 
> - since we make more and more use of the invalidated bounds idea (now
> thinking of exposed areas) we should seriously think about improving
> the system one step further. The MM player can deal with /multiple/
> invalidated bounds. Having just small changes in two opposite corners
> of the stage does /not/ lead into a complete re-rendering like Gnash
> does currently. Instead, it uses two small, individual rectangles
> which is a huge performance gain in certain cases. This is not that
> difficult to implement as long we find an appropriate method to pass a
> whole /list/ of rects along get_invalidated_bounds() and find a good
> algorithm that merges near invalidated bounds into a single one.

Same applies to exposed regions, you can have a window covering
the *middle* of your flash animation, resulting in 4 exposed
rectangles (top/left/right/bottom).
The algorithm should be able to also intersect these (possibly
overlapping)

> - I have the *strong* feeling that the MM player internally works with
> sub-frames (see my post in the video thread). Regardless whether this
> is true, it has two advantages: First, it allows videos to be played
> at a faster frame rate than defined while still not killing when
> multiple videos need to be played. Same applies for mouse events
> ("immediate events"). Second, it can do throttled (at subframe rate)
> redrawing while resizing. GTK seems to wait for mouse release but
> under Windows content is updated while dragging. The biggest advantage
> would be for the videos, though.
> However, this could be implemented easily by calling display() at 10
> times the nominal frame rate and call advance_frame() at the right
> times. The invalidated bounds will be NULL in most frames unless a new
> video frame is available or the GUI overrides them because it wishes a
> re-draw.

Agreed [renderer] could be called at an higher rate, but I dunno if
it whouls be bound to FPS at all (maybe could be a copile-time or run-time
setting).

> I think I wrote enough for a good sleep ;)

Will follow you ;)
--strk;

> 
> Udo
> 
> 
> 
> s> We need 3 distinct functionalities here:
> 
> s>         1) Advance the movie playhead.
> s>            Includes runnign actions, we want to always do this
> s>            at *regular* intervals - SWF specified FPS.
> 
> s>         2) Render the stage to a buffer.
> s>            We want to do when something changes on the Stage due
> s>            to system [ie. enterFrame] or user [ie. mouseOver] events.
> 
> s>         3) Draw (possibly portions of) the buffer onscreen.
> s>            We want to do when the (exposed) on-screen copy does not
> s>            match the (corresponding region of) off-screen buffer,
> s>            either due to changes in the off-screen buffer (see [2])
> s>            or to data loss (the portion of window was just exposed).
> 
> s> What would be better done by which actor ?
> 
> s> Avoiding calling Gui::display from Gui::advance_movie would make
> s> the Gui::advance_movie cover funcionality number 1 in the above
> s> list, which sounds correct. Granted :)
> 
> s> As for Gui::display, it currently covers both (2) and (3), so
> s> we should split it as well.
> 
> s> Pure functionality (2) seems to be covered by Gui::renderBuffer
> s> (currently called by Gui::display)
> 
> s> --strk;
> 
> 
> 
> 
> Udo

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.