[Dan East]

I've done game development on mobile devices in the past, and am interested in seeing how far the Blackberry can be pushed. Windows CE (aka Windows Mobile) has a simple direct-screen access API, which provides direct access to the display RAM. Of course the display properties vary by device, so the programmer has to take into consideration all the various display possibilities. However, the benefit is extremely fast graphics performance.

Does RIM provide any such direct access?

If not, what is the fastest method of writing pixels directly to the screen? I'm taking about modifying every pixel on the entire screen every frame.

My current test has a thread which invalidates the display 100 times a second. I have an integer array whose size is the number of pixels of the display. I have a bitmap which is the size of the display. Each time paint is called I set my array to the bitmap using setARGB, then I drawBitmap it to the Graphics object. This runs at 9 FPS. If I add a simple loop which writes to each pixel in my array, then it drops to 7 FPS.

Here are some benchmark values:
Only calculate FPS in paint(): 28 FPS
Calc FPS, drawBitmap: 26 FPS
Calc FPS, setARGB, drawBitmap: 9
Calc FPS, modify pixel buffer, setARGB, drawBitmap: 7

As you can see, setARGB is the big performance killer. If I could simply write to an int array that is the actual display, without requiring the entire array to be copied every frame, then it might be possible to pull of some decent (GBA-like) gaming on the Blackberry.

[Dan East]

Okay, I've been able to improve performance, but now I'm running into garbage collection pauses and the performance penalty of dealing with non 32-bit integers.

The native display format for the Pearl (and probably all color devices) is 16 bit RGB 565. So the best performance uses a raw buffer in the native format. The only way I can find to set a bitmap to a buffer of a type other than 32 bit ARGB is the Bitmap constructor. When constructing a bitmap each frame with my raw data in RGB565 and then drawBitmap I get 13 FPS. However, because I'm creating a new bitmap every frame the garbage collector is called every couple seconds, which causes a significant pause.

I can't find anyway to set the Bitmap's raw data from types other than 32 ARGB, which the Bitmap must be converting to 16 bit which makes it terribly slow.

My other issue is iterating and setting values in a byte array is much slower than doing so to an int array. I'll post about that in another thread.

[RemyJ]

Have you looked at the javax.microedition.lcdui.game package? I wonder if it's performance would be any different?

[Dan East]

Thanks for the suggestion. A quick look through the API shows only ARGB support for setting raw image data (whether drawing raw data to a Graphics object, or setting the data to an Image object). Obviously the API is designed for standardization and compatibility and not performance.

This will have significant ramifications for RIM in the near future. They are now trying to compete head-to-head with the iPhone. Throwing in a touch screen is not nearly enough - the iPhone is a multimedia powerhouse. Java is already a major detriment to the BB in this area, because it abstracts the hardware too much to allow the type of optimizations required to wring every cycle out of the weak, integer-only CPUs in these devices. RIM is exacerbating the problem by not showing enough foresight to allow developers to work in types native to the processor. In this case, the inability to work with image data of a hardware native format (RGB 565) in a type optimized for the CPU (32 bit integer).

[Dan East]

Here's an example of how this type of thing should be handled:
DirectGraphics (Nokia UI API)

Nokia provides a class, "DirectGraphics", which provides direct access to the device-specific display. You'll note a routine, "drawPixels", which has three variations supporting raw image buffers of byte, short and int types, which allows the developer to work with the native pixel format for maximum performance.

[CELITE]

The speed issue is a huge limitation of the blackberry platform that I have fought with for years. There are little hacks you can do to improve performance, but not by any significant margin.

Also, you will sometimes see good performance on OLDER devices. This is often because the framework changed (for the worse) in handling things like painting screen backgrounds.

Also regarding RGB565, you can set it per frame instead of creating a new object with setRGB565 in 4.6 of the JDE

[webmasterpdx]

It takes a while to find the right APIs....but Blackberry's net.rim classes are all custom to the blackberry devices....and are optimized. In 4.7 is the following set of libraries.

* javax.microedition.lcdui Canvas, Form, Gauge, Graphics, Image, List, Screen
* java.microedition.lcdui.game GameCanvas, Layer, Sprite
* net.rim.device.api.lcdui BlackberryCanvas,CustomItem,Form,List,Textbox
* net.rim.device.api.lcdui.control Virtual Keyboard controls
* net.rim.device.api.lcdui.game BlackberryGameCanvas
* net.rim.blackberry.api.menuitem
* net.rim.blackberry.api.homescreen
* net.rim.blackberry.api.browser
* net.rim.device.api.browser.field Browser interfaces
* net.rim.device.api.ui
* net.rim.device.api.ui.autotext Magic Typing replacing words.
* net.rim.device.api.ui.component All the fields, dialogs, etc..
* net.rim.device.api.ui.container Managers different screens and flow.
* net.rim.device.api.ui.decor Backgrounds and Borders
* net.rim.device.api.ui.text Text filters
* net.rim.plazmic.mediaengine mediaplayer
* javax.microedition.m2g
* org.w3c.dom.svg Vector Graphics

Now, mathematics is another way to increase speed. Use of Fixed32 and VecMath really accellerates a lot of functionality. I use these to do 2D transformations and it works great, and it's fast.

Good Luck.
-Donald