(this applies to the whole Gnash playback architecture)
After advancing the root movie (see gnash::Gui::advance_movie) it is checked which region of the stage has been changed visibly (by computing the bounds around updated characters). This has two advantages:
1st, it allows a renderer/gui combination to avoid re-rendering of unchanged parts in the scene. When supported by the rendering engine this can be a huge performance gain. The original Flash player does that too, btw. Altough he is able to define multiple smaller regions for one frame. This could be implemented in Gnash, too.
2nd, it can detect still frames (like a stopped movie). gui.cpp can detect these and completely avoid calling any rendering function.
Of course, the most critical part is detection of changes. There is a method gnash::character::set_invalidated() which gets called whenever a critical property of a instance gets updated, like when it changes position, for example. It's really important to *always* call set_invalidated() *before* any call that changes the character instance in a visible way.
Even if no renderer really uses this information it has effects when skipping unchanged frames. If necessary, this feature can be switched off easily in gui.cpp (maybe using a runtime option?).
Note the updated region is only passed to the gnash::Gui, which is itself responsible of informing the renderer (see gnash::Gui::set_invalidated_region). This is because it's pointless to have a renderer which updates only a small part of the stage when the GUI shows it all since the area around the region is undefined. However, there can be a GUI which supports update regions without needing the renderer to do so (for example, to save time during blitting). The GUI can also completely ignore the region information.
It's also importanto to note that the bounds passed to the GUI are just a hint and the GUI /is/ allowed to further process and alter the information in any way.
As for the integer/float discussion: I used SWFRect (floats) because all the bounds calculation involves floats anyway and so it's probably faster than converting between ints and floats all the way.