[Scummvm-devel] Framebuffer

Kostas Nakos knakos at phys.uoa.gr
Sun Jun 17 10:50:44 CEST 2007


Max Horn wrote:
> * A more refined API to tell the backend about "dirty" areas might be  
> helpful. Or not. I can't really judge whether ports would benefit.  
> For desktop machines, though, it seems that on modern machines, esp.  
> when using expensive scalers, it can be much more efficient to have a  
> copy of the previous frame around, then do a pixel-by-pixel check to  
> compute all pixels that need to be updated, and then update  
> everything at once. This might be totally different for low end  
> devices, though. I am reluctant to implement anything in this area  
> without knowing whether there are any benefits, though. Hence,  
> porters, if you can think of potential improvements (like a  
> 'OSystem::markRectAsDirty' method), tell me, and promise to work with  
> me on testing the theory :-).

My experience in WinCE has proved that implementing a dirty update 
scheme makes the difference between real-time and slow performance, on 
more than the average case. The reason is that palette translations + 
scaling turn out to be rather expensive, so the less performed the 
better (I have to convert from 8pp to 16bpp 565 or 555). Note that the 
current draw path for wince scummvm is: 8bpp->(dirty areas)16bpp->(dirty 
areas)scaler->(dirty areas)copy to device screen with rotation.

I other wince projects, I've been doing dirty updates using two schemes 
which differ slightly between them but they boil down to comparing 
against the previous frame in either batches of 4 (unit32 comparison) or 
8 pixels (more elaborate & complicated scheme), then if they're 
different the new pixels get translated, scaled etc.

There are obviously 2 ways dirty areas get generated in scummvm: 1) An 
engine knows which areas are being repainted through the logic of the 
scripts, 2) The frame is compared against the previous one for changes. 
I gather that (1) is extremely difficult to do universally so we're left 
with (2). Further I'm not sure it's worth the trouble to go around 
collating areas of changed pixels to rects, instead of just scanning the 
frame and directly updating pixels. But since we've already got a 
rect-based thing going which performs very nicely, maybe we can stick 
with it. Also, I'm not sure how/if we can have rect-based updates & 
pixel based updates at the same time.


So to sum up, we definitively need a dirty update scheme. The specifics 
of it are not clear to me right now, but maybe we should look in the 
direction of somehow extending what's already in place.

Best,
Kostas




More information about the Scummvm-devel mailing list