scummvm/scummvm — pull request #320 by johndoe123 (2013-04-18 17:51:54+00:00)
Title: Optimized graphics drawing for Sword25

Here's my attempt at optimizing the drawing code of Sword25. With the original code a screen update took about 10ms on my machine, with this change the time isn't measurable with a simple getMillis(). I played a few rooms and didn't notice any glitches.

What it does:
Before the sprites are actually drawn, a list with the bounding boxes of all visible render objects is built. Each element in this list contains the render object, the "version" [1] of the object and its bounding box.
This list is compared to the list from the previous frame to find out what changed since the previous frame. Each changed rectangle is inserted into a microtile array from which a list of the actual update rectangles is created.
Then render() is called with this list and each render object only draws the parts of itself which intersect with an update rectangle.
After this each updated rectangle is simply updated with copyRectToScreen.
It was optimized further by testing which render object intersection an update rectangle is solid and would overdraw the underlying graphics. Now only render objects which are in front of this solid render object are drawn. This speeds up the main menu a little, for example, because the static flames background don't have to be drawn.
Another optimization is that after loading a static bitmap it's checked if it's transparent at all (i.e. has alpha values != 255). If not, it will simply do a memcpy when blitting the bitmap. This is currently only enabled for LE systems. Also when alpha-blitting, instead of outputting the values byte-wise, it outputs a uint32 value with the RGBA values which should be a little faster (not done for BE systems).

[1] The "version" changes when the render object has changed, e.g. it's position or the pixel content.