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

[Max Horn]

Am 10.11.2009 um 16:33 schrieb Vladimir Menshakov:

> Oh, let's try from the very beginning.
> Let's divide engines (from scummvm and future ones) into three groups:
> 1) LockScreen() -> draw something -> unlockScreen(). Fullscreen  
> update on every frame. Backend does not know about modified pixels.
> 2) Creating backbuffer, draw everything in it.
>  a) Blit backbuffer into screen. 2 fullscreen updates on every frame.
>  b) Blit dirty rectangles with copyRectToScreen, Fullscreen update +  
> bunch of rectangle updates.
> 3) Creating surfaces for every dirty rectangles (colorkey blit into  
> it), then later call copyRectToScreen.
>
> Backends maintains:
> 1) its own dirty lists for blitting
> 2) its own backbuffer. or not. :)
>
> So we have multiple variation of dirty rectangle code everywhere on  
> every level of graphics code.
>
> Adding LockRect solves many problems for engines as it informs  
> backends about rectangle modified by pixel update.
>
> 1) We could blit actors/cursors/animation colorkey or alpha-blending  
> sequences without fullscreen updates every time.
> 2) No extra 'dirty surfaces' code in engines.
> 3) Actually CopyRectToScreen() could be replaced by LockRect(rect,  
> kWriteOnly);
> 4) Unification of dirty rectangles calculation in all backends, as  
> we have full-access to pixel data without full screen invalidation.

OK, that's already much clearer, and now that you explained the goals  
(instead of just the solutions to unclear goals :), it's possible to  
discuss this :).

One major issue with this is that it seems like a major task which  
requires lots of changes to all engines and backends, i.e. requires a  
major coordinated effort. In principle, this is doable, but before  
even thinking about it further, I wonder what the actual benefit are...

You explained the theoretical benefits (and I like them ;), but what  
real-world issues are solved by this? Like, can you name some specific  
specific combinations of devices and games which currently have issues  
which cannot be resolved in the current OSystem design, or which are  
hard to solve with it; and which would become "easy" to resolve with a  
hypothetical revised API as you propose it ?

You named engines which might benefit from a colorkey enabled blitting  
API, etc., but it is not clear to me whether any of those actually has  
issues which the new API would resolve.

Note that some engines do full screen updates because their engines do  
no dirty rect tracking at all, and rewriting those engines to  
implement dirty rect tracking seems about as complicated as modifying  
them to use the new API -- so the gain of the new API is not  
immediately clear to me. And other engines use palette cycling, which  
forces fullscreen updates anyway.


Cheers,
Max