GapiDraw 2.0 development progress

[Johan]

[Daily update - Sunday, April 20]

(1)
CGapiRGBASurface can now be either 16 or 32-bit (set using a flag in CreateSurface). Right now the performance of them are about the same (with the 16-bit 4-4-4-A RGBA version taking 50% less memory of course). I will add some more flags to AlphaBlt for more customization...

(2)
Support for incoming call minimization on Smartphones in CGapiApplication

(3)
I have decided that this really is GapiDraw 2.0 and will change the DLL and LIB versions accordingly.

(4)
I have begun working on updated documentation.

Next build will be out tomorrow or on Tuesday.... And it will be 2.0 beta...

[Johan]

[Daily update - Monday, April 21]

Since many games seem to use alpha blends I decided to try and improve performance some...

(1) CRGBASurface
Storing alpha and image information together resulted in a nice performance boost on the Pocket PC. How much? It depends on the image really... On stationary PCs with their larger cache the performance was about the same..

(2) Using LUT for multiplications
I tried rewriting the current formulas (where two multiplications are required for each pixel) with three memory lookups. I created a 4kb LUT that used 4 bits of alpha and 5-bits of color information. After some hours of tweaking I found out that the current way with two multiplications is much faster. So much for look up tables...

No new build today.. The weather is far too nice to stay indoors...

[efortier]

[Sm!rk]

[Johan]

[efortier]

[Hosed]

LUTs are just an optimization option and like all optimizations, has it's time and place. They're useful, but not as a wholistic solution to all problems. As efortier said, sin/cos/tan luts are very useful. Namely because trig functions concist of atleast a couple dozen adds/divs/muls when expanded to series form (and all computers implement them in this form).

[Johan]

[Daily update - Tuesday, April 22]

"leet hacking".. Today I increased the performance of BltFast with key source up to 40% (this also includes BltFast + keysource + opacity, and BltFast + keysource + colorfill + opacity + whatever).. The previous BltFast always operated on one pixel at the time. The new BltFast operates on multiple pixels simultaneously. The trick was to get this to work with the current template meta programming architecture (which actually works out really well).

Performance speaks for itself. The MFC demo as re-programmed by Walter Rawdanik (owner of ZSurface, http://www.warmi.net/zaurus/blits.shtml ) in optimized ARM Assembler produced 290 sprites on each frame on the IPAQ. That is the current limit. GapiDraw 2.0 is now able to produce 270 sprites on that device. That is a mere 7% difference in performance.

AlphaBlendFast was also improved to work on multiple pixels (together with an overhaul of FillRect and a couple of other operations). As soon as I have QA'd all code I will release the first 2.0 beta (Thursday). Walter: Lots of thanks for the comments + input!

Oh, finally some further Smartphone-related changes to CGapiApplication. Thanks to all of you who have emailed!!



Note: If you look closely at the image you may notice a small cosmetic error to some sprites. This was related to a small programming error and has been corrected. The correction did not alter performance.

[stuff]

[spacemonkey]

[stuff]

[Johan]

[Daily update - Wednesday, April 23]

I have taken the time to rewrite most of the core operations, such as BltFast, AlphaBltFast and FillRect. BltFast and AlphaBltFast are now around 20-40% faster depending on data. FillRect has been "cleaned up" to allow for some nice cache re-use..

The rewriting of the core blit operations was planned for a long time, but I always felt that rewriting the core features would risk imposing errors in the rendering pipeline. It did not suit a 1.05 or a 1.1 release. With the release of a 2.0 version, there could be no better time to implement this. Thankfully it is very easy to test graphics code like this, and GapiDraw has never had any visual anomalies in previous releases.

The improved AlphaBltFast (when using separate surfaces for image and alpha) is now also significantly faster than the new RGBA surfaces.. <sigh>.. To simplify the use of the "old" alpha way I added a feature to CreateSurface: GDSURFACE_ALPHASURFACE. If you load a PNG image to a surface and set the flag GDSURFACE_ALPHASURFACE, the PNG loader will extract the alpha information stored in the image and set color values between RGB(0,0,0) and RGB(255,255,255). In other words, there is no longer a need to use the "alpha split" macro anymore, even if you use separate surfaces for image and alpha.

Now it's time for some serious testing of all the rewritten blit operations before I post the first 2.0 beta tomorrow.

stuff: It should be enough to capture WM_ACTIVATE. You never actually have to deal with SET/KILL focus. Please test the next build tomorrow and see how it works on your device.

*UPDATE* The RGBA surfaces are actually much faster when doing AlphaBlt (stretch). So the work done on creating them are not wasted after all!! Here are some figures:

--DESKTOP-

10 000 alpha blended sprites, AlphaBltFast (200x200)

2844 - 16bit RGBA aligned
2437 - 32bit RGBA aligned
2609 - 1.04 routine aligned
1984 - new routine aligned
2015 - new routine destination unaligned

1 000 alpha blended sprites, AlphaBlt (200x200)

797 - 16bit RGBA
688 - 32bit RGBA
1062 - separate image and alpha surfaces

--POCKETPC--

1 000 alpha blended sprites, AlphaBltFast (200x200)

4827 - 16bit RGBA aligned
5034 - 32bit RGBA aligned
5326 - 1.04 routine aligned
4030 - new routine aligned
4113 - new routine destination unaligned

[stuff]

can't wait :P

[warmi]

As far as AlphaBlend performance it is possible to get down to a single multiplication per pixel if you are willing to limit your alpha value to range 0-32.

Following logic in this article
and given aligned blit you can load 2 pixels at a time in this format:

standard 32 bit (2 pixel) register:
RGBRGB

First you separate GRB part:
_G_R_B

Then you separate RBG part
R_B_G_ and shift to the right to get
_R_B_G

Given this setup you can now do multiplication on
each register which will result in 2 multiplications
per 2 pixels.
The reason you are limited to max 32 alpha levels, is that we have only 5 bits to work with before we overflow into set of bits for another color ( these 5 bits were represented as _ in the above diagram.)

Basically you exchange multiplication for a shift/AND operation.
This can only be done on aligned pixels and works best (best performance) for static alpha blends ( alpha value is constant for the entire blit.)

[Johan]