[Scummvm-devel] Framebuffer

Kostas Nakos knakos at phys.uoa.gr
Tue Oct 24 12:10:09 CEST 2006

Max Horn wrote:
> Now, what do you our porters say? I'd like to hear whether this move  
> would complicate or simplify your code -- or neither (besides the  
> fact that you'd have work to make the transition, of course). And  
> would it likely cause a speed penalty, and improvement, or again,  
> nothing?

Setting aside the adaptation effort to the proposed API, it is generally 
hard to account for every possible side-effect.

The new method reduces the total number of screen buffers needed and 
this is good. It can also lead to more tightly coupled - and hence 
better optimized - compare->blit loops for modified pixels, or even 
compare->palette_lookup->blit loops thus discarding the intermediate 
"paletted_to_truecolor" buffer. Hierarchical region updates, such as the 
one proposed by Torbjörn, also speed up processing a lot on slower devices.

I'm pretty sure though that backend code will grow more complex-looking 
by cramming all those operations in a tight loop. But I do not have a 
problem with that, as long as there is a performance or memory footprint 
improvement I do not mind at all.


More information about the Scummvm-devel mailing list