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

[Udo Giacomozzi]

Hello strk,

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

Blitting (bit blitting) means "large" portions of memory are copied to
the on-screen memory framebuffer, which is often accelerated by
hardware. In general, the access to the RAM memory of the graphics
card is slower than the main system memory and so usually rendering is
done in an off-screen buffer and then "blitted" (copied) to the
on-screen buffer, which also avoids flicker.

This may not be complete or really exact but at least explains what I
mean with blitting :)


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


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

Anyway, let me underline that the invalidated bounds and the
re-rendering bounds are completely distinct things. In the easiest
solution (our current one) they're identical but that is not
necessary.

Optimally, the clipping region is calculated this way:
- the invalidated bounds (what *needs* to be redrawn)
- *extended* to lately uncovered parts
- *intersected* to the current visible area



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

Indeed. This must be done very carefully, though. Clipping actually
/decreases/ rendering performance because of added checks but is
at the same time a performance /gain/ because in total less pixels
need to be calculated. This means the algorithm must do a good job to
decide if near rects should be combined or not. This definitely
depends on the renderer *and* the GUI (for a variety of reasons) and
should be *at least* configurable or at best be a virtual class.


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

Agree, it could be a fixed inter-frame time as well (1/30th second or
so). At least the MM plugin seems to be bound to the fps as video
(30fps) is /not/ rendered smooth with very low fps (0.1).

Udo