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

[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. 


10.11.09, 15:14, "Max Horn" <max at quendi.de>:

> Am 10.11.2009 um 14:54 schrieb Vladimir Menshakov:
> >
> >
> > 10.11.09, 14:27, "Max Horn" :
> >
> >> 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  
> how?
> >
> >>> 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?
> Bye,
> Max
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel