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

[Vladimir Menshakov]

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?
As far as I know, if you use lockScreen/unlockScreen, backend will redraw full screen. There are engines (look below for a quick list) which could optimize its output without heavy modifications because they were designed with dirty rects in mind. 

Ok, I'm not insisting on extending copyRectToScreen api(maybe for nothing, because I believe it could be accelerated on portable hardware), this was an alternative to LockRect(). 
LockRect will add only specified rectangle to backend's dirty list ( as it copyRectToScreen does). 

> >
> >>> 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?

Briefly grep shows me Kyra, SCI and TeenAgent. Drascula uses internal backbuffer and memcpy it into screen. (fullscreen update again, haha). Agos (color key 0).  MADE copies SFX rect (via lockScreen). Parallaction (transparent_color in gfxbase.cpp). Logically, colorkey used everywhere, because you could not draw actor on background without alpha/colorkeying or pre-allocated surfaces. Common video player is also locking fullscreen and update part of the screen, which could be accelerated by lockRect
 
> 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