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

Vladimir Menshakov whoozle at yandex.ru
Tue Nov 10 16:56:31 CET 2009


Just an illustration. I took MADE engine from the grep "lockScreen" output: 

I know nothing about its code, but I see there could be major problems, because it call lockScreen on every rectangle it copies to screen. For real. 

Five minute patch porting it to new api: 

Index: engines/made/screenfx.cpp
===================================================================
--- engines/made/screenfx.cpp	(revision 45694)
+++ engines/made/screenfx.cpp	(working copy)
@@ -219,7 +219,17 @@
 	byte *source = (byte*)surface->getBasePtr(x1, y1);
 
 	Graphics::Surface *vgaScreen = _screen->lockScreen();
-	byte *dest = (byte*)vgaScreen->getBasePtr(x1, y1);
+	/*
+	Common::LockData {
+		Common::Rect rect;
+		uint pitch;
+		uint _mode; //private
+	}
+	*/
+	Graphics::LockData lock(Common::Rect(x1, y1, x2, y2), kWriteOnly);
+	byte *dest = (byte*)_screen->lockRect(lock);
+	if (dest == NULL)
+		error("lockRect() failed");
 
 	int16 addX = x2 / 16;
 
@@ -256,14 +266,13 @@
 		}
 
 		source += 320;
-		dest += 320;
-
+		dest += lock.pitch;
 	}
 
 	vfxHeight = (vfxHeight + 1) & 7;
 	vfxOffsTablePtr = &vfxOffsTable[vfxOffsIndexTable[vfxHeight] * 8];
 
-	_screen->unlockScreen();
+	_screen->unlockRect(lock);
 
 }
 
Anyway, please do not point to the fact that this code does not use pixel data from the locked rectangle. ;) (this code indeed needs to be ported to copyRectToScreen)
And If backend creates its own backbuffer, it could return backbuffer's pixel data with backbuffer scanline size as pitch. No extra allocation needed at all. 


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




More information about the Scummvm-devel mailing list