GAPIDRAW FEATURES

Hardware Acceleration Support

GapiDraw provides a direct 1:1 bridge to the DirectDraw library on stationary PCs and Windows Mobile devices with hardware acceleration. Even the coordinate systems are identical! Thanks to a flexible internal software architecture it is easy to add support for other hardware acceleration libraries in the near future such as Open GL ES. To find out what features are hardware accelerated in GapiDraw please refer to the online documentation.

The Software Blitter

The software blitter in GapiDraw has been designed from the ground up based on the following three principles:

Expandable. It should be easy and manageable to add new features to current blit operations, without adding large blocks of source code as a result. GapiDraw uses a programming technique called Template Meta Programming in C++ which makes the source code both easy to expand as well as very high performance. Several of our source code customers have expressed great satisfaction with the modular design of the GapiDraw graphic architecture.

High Performance. Images in GapiDraw are stored in something referred to as surfaces, a 16-bit image format. Since all modern processors today can operate on at least 32 bits of information at the same speed as they operate on 16 bits, all pixel routines in GapiDraw are fine tuned to always operate on 32 bits of information. As an example, drawing surfaces with opacity will only require one multiplication per pixel since even the multiplication can operate on multiple pixels thanks to some clever bit shifts and 32-bit logic!

Native Orientation Rendering. Every software-based display has a frame buffer stored in RAM. When you read a byte from the frame buffer, the cache in the device will automatically pre-fetch the next couple of bytes in the background. To take advantage of this, every graphics loop in GapiDraw always operates in a cache-optimized way so that if many pixels are to be read from the frame buffer, most of them will be read from the processor cache. GapiDraw will even prefetch four cache lines in parallel for maximum performance. Considering that the display can be rotated in any possible orientation (left, right or upside down), it becomes quite a big task to realize this cache-optimizations for yourself in a stable and performance efficient way if you should choose to develop your own graphics engine. Using GapiDraw you can focus on the content, not on optimizing the rendering performance in every possible display configuration.

Surfaces

Jack the Uni-Psycleby Discord Studios.
Click for larger version.
Made with GapiDraw.

A surface is an image area which you can use for drawing. You can copy other images to this area, or access it directly for custom pixel effects.

In GapiDraw, even the display and the back buffer are two surfaces. Thus, to draw to the backbuffer, you typically create a new surface, load an image into that surface, and draw it onto different positions on the back buffer to simulate movement.

GapiDraw supports three types of surfaces: opaque surfaces, surfaces with 1-bit transparency mask (like GIF images), and surfaces with variable alpha (like PNG images) - called RGBA surfaces. RGBA surfaces are used for all Windows Vista graphics, and is also used for all graphics on the popular iPhone and iPod Touch handheld devices.

Zero-Overhead Image Loading

Memory on handheld computers is precious and should be used as sparsely as possible. Many legacy applications use the image loading routines from Virtual Office Systems that provide a direct link to the system built-in image decoders to load PNG, JPG, GIF and BMP images from a file, resource or memory. The built-in image decoders however have one significant drawback: they use huge amounts of memory!

To give an example. A typical game stores pictures as PNG images on disk. The images are 8-bit indexed color, and the final decompressed image should be stored as a 16-bit image in a format combatible with the display. The amount of memory required when using the built-in image decoding routines are a (1) the size of the file as loaded into memory (this can be minimized by using memory mapped files), (2) the size of the file as expanded to 24-bit true color (which is necessary since the built-in routines does not expand to the 565 display format on all devices), and (3) the size of the final 16-bit surface. Given an image that is 2000x1000 pixels, the minimum amount of memory required to load the bitmap is (2000x1000x24bit + 2000x1000x16bit) = 9,77 mb using the system built-in image decoder.

Instead of using these decoders GapiDraw includes custom-written PNG and BMP image decoders with nearly zero memory overhead! Loading an image of 2000x1000 pixels will only require 3.91 mb using GapiDraw's proprietary image decoder (~2.5 times less memory)!

In most graphics operations, GapiDraw accepts several flag parameters that changes how pixels are to be copied between surfaces. Examples are transparency, color masks and colorizations. Implementing support for three flags, a developer can write either one loop that covers all flags or eight individually optimized loops. Writing eight different loops for three flags means having to write another additional eight loops if a new flag is added to the API. In some operations, GapiDraw accepts up to eight flags as parameters. Writing one loop imposes significant performance issues in that all flags have to be checked for every single pixel being copied, whereas writing 256 individually optimized loops results in un-manageable source code.

GapiDraw supports multiple display formats such as 16-bit 555 and 16-bit 565 formats. Using Template Meta Programming, all blit loops are copied by the precompiler to generate unique and optimized loops for every display configuration! The result is simply stunning performance!

Detailed Feature List

If you click on one of the links below you are taken straight to the GapiDraw documentation where you can read more about the specific topic.

Application Framework for RAD development

Proven OS integration. The GapiDraw application framework is centered around an easy to use class CGapiApplication that serves as the starting point for your application. The application frameworks takes care of every possible OS event such as minimizing due to incoming phone calls, warning signs due to low battery or other notifications. The GapiDraw framework has been improved during many years, and tested on tens of thousands of devices.

The option to set and modify the maximum number of frame updates per second (FPS). Limiting the maximum number of frame updates per second has several advantages, such as prolonging battery life. GapiDraw features an advanced timer class that adaptively analyzes the number of frames rendered each second, and spreads out the frames in a way that guarantees smooth playback during the entire update cycle.

Sony Ericsson Xperia Panel Development

GapiDraw ships with a complete framework to develop interactive Xperia panel applications. Using GapiDraw you can run the same code either as a separate executable file (to help debugging) or as an Xperia panel DLL (for release).

Display Interface

Support for creating applications as DLL files using an "offscreen display". If you want to develop a visually advanced today screen plugin, a DLL file, or a Sony Ericsson Xperia panel you want to create an offscreen display using GDI which you can then copy to the display. GapiDraw has been used in numerous games and advanced applications for today screen plugins, and is currently in use for developing Sony Ericsson Xperia panels! Using an offscreen display you get the same blazingly fast blitter performance as in full screen mode, with the flexibility to blit in a window or a panel.

Extensive back buffer support. On devices without DirectDraw, GapiDraw supports three different types of back buffer configurations, all of which are used today on various devices. The first type is where display access is direct, and the application itself has to manage the back buffer and copy it to the display. The other type is where the application manages the back buffer and notifies the system to update the display using the back buffer provided. The third type is where the back buffer is buffered and where the system will copy it to the display itself.

Extensive display support. Every single blit and graphic drawing routine in GapiDraw supports 15-bit as well as 16-bit displays with no per-pixel conversion in the final blit to the display. Everything is rendered internally exactly as it will look on the display, which is one of the reasons GapiDraw performs so well. GapiDraw can provide support for all these display types while still performing well thanks to the Template Meta Programming technique used (see the information box to the left).

Object Oriented class structure - both the display class as well as the back buffer class inherits all the drawing and blitting features from the surface class, meaning you can draw and copy images to them freely.

Draw to the display in any orientation with no performance loss. Typically, handheld computers use a portrait oriented display in a resolution such s 240 x 320 pixels. GapiDraw can use this display as either a 240 x 320 display, or a 320 x 240 display, in any orientation (0, 90, 180, 270 degrees rotation) without any performance loss due to advanced internal coordinate transformations. By default GapiDraw will use the orientation used by the operating system, this can however be changed at any time when the application is running - GapiDraw will then internally rotate all bitmaps to fit the new orientation for maximum performance.

Clipping support, you can set an area that equals either the full surface or a part of the surface, and all graphics drawn to the surface will only be painted within that area. This works for all GapiDraw operations, and all GapiDraw operations have been specifically optimized for clipping. This means that there are no pixel-by-pixel checks done to see if it's "inside" the clipping area or not.

Color key support, to set a color that will be transparent when copying images from one surface to another

Surface Intersections

Surface-to-surface intersection. This highly optimized routine will first perform a bounding box check of two surfaces, and then do a pixel-by-pixel scan of just the overlapping area to see where they intersected. The surface function Intersect() will even return where the surfaces intersection so you can draw appropriate effects at the right location.

Collision mask-to-surface intersection. If you have a game like a flipper game you can set up a large collision mask surface which you can use to check if another surface like a flipper ball intersects with specific colors upon that surface to check for intersections

Bitmapped text that can be left, right or center-aligned with opacity. Text kerning can be individually set between characters to provide advanced typography solutions.

Font Support

Built-in system font that can be used for debugging output. The system font comes in two options - one with a thin border and one without. The built.in system font can be re-created at any time with a custom color.