Re[2]: [Gnash-dev] gui wants redraw

[Udo Giacomozzi]

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.
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

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.

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().

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.

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). 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).


So far for the original question. I hope it's clear now what I want to
tell.


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.

- 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.


I think I wrote enough for a good sleep ;)

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