[Top][All Lists]
[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: |
Tue, 7 Nov 2006 01:28:59 +0100 |
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.
- Re: [Gnash-dev] gui wants redraw, (continued)
- Re: [Gnash-dev] gui wants redraw, strk, 2006/11/05
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/05
- Re: [Gnash-dev] gui wants redraw, strk, 2006/11/06
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/06
- Re: [Gnash-dev] gui wants redraw, strk, 2006/11/06
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/06
- Re: [Gnash-dev] gui wants redraw, strk, 2006/11/06
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/06
- Re: [Gnash-dev] gui wants redraw, strk, 2006/11/06
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/06
- Re: [Gnash-dev] gui wants redraw,
strk <=
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/07
- Re: [Gnash-dev] gui wants redraw, Bastiaan Jacques, 2006/11/09
- Re[2]: [Gnash-dev] gui wants redraw, Udo Giacomozzi, 2006/11/21