[Scummvm-devel] Minimal screen updates and possible OSystem improvements

Max Horn max at quendi.de
Tue Nov 10 15:14:13 CET 2009

Am 10.11.2009 um 14:54 schrieb Vladimir Menshakov:

> 10.11.09, 14:27, "Max Horn" <max at quendi.de>:
>> Hi Vladimir!
>> Am 10.11.2009 um 13:14 schrieb Vladimir Menshakov:
>>> Good day, everyone!
>>> I hope you could tell me about "minimal updates" approach in
>>> scummvm's OSystem. I found several possible oversights in API:
>>> 1. copyRectToScreen() does not support colorkey or alpha blits.
>> This is not an oversight, this is intentional -- OSystem does not
>> support colorkey nor alpha blits for the screen surface, and there  
>> are
>> no plans currently to change that.
>>> 2. lock-unlockScreen() invalidates whole screen (for obvious  
>>> reasons).
>>> Something easily could be done here:
>>> 1. We could implement various copyRectToScreen variations (colorkey,
>>> alpha, colorkey + alpha). Or, at least, colorkey, I'm pretty sure it
>>> could be accelerated in the most embedded backends.
>> OK, but to what end? Which frontend code would benefit from that??
> I've heard about psp problems with fullscreen-every-frame-updates.  
> Anyway, such simple optimization could save cpu cycles.

This does not answer my questions. In particular, if we add alpha /  
colorkey APIs, those have *no effect at all* unless some code actually  
uses them :-). I.e., a new API alone solves nothing, and has to be  
considered in context.

So, to rephrase my questions: Which code are you thinking about here?  
I.e. which *concrete* code paths do you think this would improve, and  

>>> 2. Add lockRect()/unlockRect functions, returning pixel data
>>> pointer, and pitch info (usually screen scanline width) which
>>> invalidates only requested rectangle.
>> Same as above: Which application do you have in mind? At first  
>> glance,
>> these would only be helpful if some code needs to read a rect from  
>> the
>> current screen, modify it, and write it back. Otherwise, one can
>> simply use copyRectToScreen().
> How could dirty rectangles updates(with colorkey or alpha) could be  
> implemented on top of copyRectToScreen?

Again, which engine needs colorkey and alpha?


More information about the Scummvm-devel mailing list