[Scummvm-devel] Dirty updates (Was: Framebuffer)

Max Horn max at quendi.de
Sun Jun 17 21:17:27 CEST 2007


Hi Kostas, all,

you raise some very good points, although I think they are mostly  
independent of the new framebuffer API.

What I really would like to see is somebody taking the current SDL  
backend, creating a (temporarily) fork of it with a new rendering  
pipeline implemented. One which gets rid of any dirty *rect* code and  
instead implements proper auto dirty detection. That is, it keeps a  
copy of the last rendered frame, then when updateScreen() is called  
compares the current against the previous frame, and from this  
automatically computes which pixels have to be updated. Then we could  
run some performance comparisons; in particular it would be  
interesting to learn how this affects CPU and RAM usage (of course  
we'd need an extra buffer for the prev frame, but maybe we can save  
in other places).

There are various details to consider for this, of course: Scalers  
usually look at multiple input pixels to compute their output, so  
whenever the autodirty code sees a changed pixel, it may also have to  
dirty neighboring pixels. One way to do that w/o having to look at  
all input pixels multiple times would be to compute a "dirty bitmap",  
where for each pixel we keep a single "dirty" bit. Yes, more memory  
again -- it's a speed vs. memory tradeoff, and I am not sure which  
resource is more important in this case (and this might vary from  
architecture to architecture), so some experiments might be necessary.

Also, one has to decide what is better: Keeping the prev frame before  
or after the 8->16bit conversion. The former takes up less space and  
potentially allows us to avoid converting certain pixels from 8 to 16  
bit; OTOH, the latter approach gives us perfect "palette change  
handling" for free (for example right now in games which do color  
rotation, we always invalidate the whole screen in the SDL backend,  
even if perhaps only a few pixels changed at all).

All in all the current rendering pipeline in the SDL backend is  
rather convoluted and complex. It could certainly benefit from a  
thorough overhaul. But this is not an easy task, given the number of  
extra features one has to support: 8->16bit conversion, scaling,  
aspect ratio correction (in place), separate mouse cursor scaling,  
separate mouse palette, screen shaking, and of course the (GUI) overlay.


But automatic dirty updates might not be ideal for all backends, so  
keeping an (optional) dirty rect API might still be a good idea  
(right now we have this implicitly via copyRectToScreen/ 
copyRectToOverlay; in the future this *might* be phased out (nothing  
has been decided yet, though), but then we could still keep a  
markRectAsDirty() method (which on backends doing auto-dirtying would  
simply do nothing).

The key thing to observe here is: How a backend implements screen  
updates is entirely up to itself: Whether it always updates  
everything, tries to keep track of dirty rects, or uses auto- 
dirtying, or something else, frontend code should not care (except  
that they should if possible provide dirty rect hints, at least as  
long as we have backends that benefit from this). It would simplify  
our APIs if we could just completely drop the dirty rect part,  
though, but we can only do that if we don't hurt backends terminally  
by this. In this sense it would be nice if porters could tell us  
about their needs in this regard. I.e. if you are a porter and your  
port needs dirty rect hints, please tell us!


Cheers,
Max




More information about the Scummvm-devel mailing list