GapiDraw 2.0 development progress

[efortier]

[Johan]

[Daily update - Thursday, April 24]

Download latest build here:
http://www.gapidraw.com/GapiDraw200(2003-04-24).exe


New:

(1) Improved support for Smartphones
-Use the new configuration parameter MinimizeWhenInactive to minimize your application when an incoming call is received
-CGapiApplication will now correctly hide the task bar on all Smartphones

(2) Improved support for PNGs
There is no longer any need to split image and alpha. CreateSurface now has an additional flag: GDSURFACE_ALPHA. If you set this and load a PNG image with transparancy, the surface will contain the alpha values as a gray scale from 0 (transparent) to 255 (opaque)

(3) Improved support for RGBA Surfaces
CGapiRGBASurface is the fastest option when doing stretched alpha blends (AlphaBlt). CGapiRGBASurface can now be either 32-bit or 16-bit (using a 4-4-4-a format for less footprint) using a flag to CreateSurface.

(4) Improved performance to BltFast, AlphaBltFast and FillRect
BltFast with color key, AlphaBltFast, and FillRect are now up to 40% faster. GapiDraw will always operate on two pixels simultaneously, even when color keys are being used. Best performance is achieved if both rectangles to be copied are aligned at a coordinate evenly dividable by 2, there are however also significant improvements when this is not the case. The difference between GapiDraw C++ code and optimized ASM code is now less than 7%.

Note: AlphaBltFast with separate surfaces for image and alpha is much faster than using RGBA surfaces. AlphaBlt with RGBA surfaces is much faster than using separate surfaces for image and alpha. With the new flag GDSURFACE_ALPHA both formats are equally as simple to use. Choose what fits best.

(5) Improved performance with transparent blits and rectangles
GapiDraw now only uses ONE multiplication for each pixel when doing transparent BltFast and FillRect. No lookuptable is used either. Best performance is achieved if both rectangles to be copied are aligned at a coordinate evenly dividable by 2. This was actually one of the more difficult tasks, and I spent several hours producing what proved to be 9 rows of code.

(6) Some changes
-GDABLT_<x> and GDABLTFAST_<x> flags were renamed to GDALPHABLT_<x> and GDALPHABLTFAST<x>.
-A new flag was added to CGapiApplication: MinimizedActive, that will keep ProcessNextFrame active even when the application is minimized.

There have been a huge amount of internal changes (A couple of thousand lines of new code have been written) and I have not yet tested this version to full extent. Use at your own risk. I am however extremely grateful if you do try it out, and if you do, please post any performance improvements.

[Johan]

--- [Important changes in next beta] ---

Right now I am feeling that CGapiSurface is getting a bit too large. If I only need a surface to use as an "image store holder", do I really need all those drawing functions in all instances?

PocketFrog solved this by separating the surface and the renderer ("rasterizer"). All drawing functions are placed in the rasterizer, which is set to point to a surface. I do not want this. I used the same approach in GapiTools and it provided (IMHO) unmanageable code.

Right now I am thinking of moving CreateSurface, GetWidth/Height, GetBuffer, and some other functions to a new base class CGapiSurface. The current CGapiSurface would then be a subclass to this, called CGapiDrawSurface:

CGapiSurface
|
CGapiRGBASurface : public CGapiSurface
CGapiDrawSurface : public CGapiSurface
|
CGapiCursor : public CGapiRGBASurface
CGapiDisplay : public CGapiDrawSurface
CGapiMaskSurface : public CGapiDrawSurface
CGapiBitmapFont : public CGapiDrawSurface

How do you all feel about this? Is this a motivated change?

[efortier]

Here's some food for thought, right from my mentor's own lips:

Will this new change produce faster/smaller code?

Will it make it easier for user/programmer?

Does it fulfill a need?

If the answer to these three questions is no, then you must follow this maxim: Dont fix it if it ain't broken!

[stuff]

[spacemonkey]

[Johan]

[stuff]

[spacemonkey]

I see what Stuff is saying. So currently the gapidraw is detecting the lost focus/inactive and suspending and minimizing, if it just suspends but leaves the window open then restarts if it detects a WM_SETFOCUS then it would do what stuff wants... (kinda like on a pc when you have your game open and then open another window in front, the game needs to pause until it's the front/active window, but we don't need to minimize it.)

I'm not too fussed cos at least it comes back cleanly just by rerunning it from MRU etc.

[stuff]

[spacemonkey]

[stuff]

[Johan]

[Fuge]

[DillRye]