What is the fasted way to update the whole screen by JNI

[Eric Wang]

Hi friends,

My current code as below:

final static int W = 320;

final static int H = 480;

static short[] sPixels = new short[W*H];

static ShortBuffer sScreenBuff = ShortBuffer.allocate(W*H);

static Bitmap sScreenBitmap = Bitmap.createBitmap(W, H, Bitmap.Config.RGB_565);

void drawFrame(Canvas canvas) // java

{

    xUpdateScreen(sPixels); // call Native C code

    sScreenBuff.put(sPixels);

    sScreenBuff.rewind();

    sScreenBitmap.copyPixelsFromBuffer(sScreenBuff);

    canvas.drawBitmap(sScreenBitmap, 0, 0, null);

}

// Native C

short* g_Buff = NULL;

void Java_xxx_xInit(...)

{

    g_Buff = (short*)malloc(W*H*sizeof(short));

    ...

}

void Java_xxx_xUpdateScreen(JNIEnv* jEnv, jobject jObj, jshortArray jArr)

{

    // update offscreen g_Buff

    ....

    jEnv->SetShortArrayRegion(jArr, 0, BUFF_SIZE, g_Buff);

}

I have couple of questions here:

(1). In Native C code, the SetShortArrayRegion operation must copy all the data from g_Arr, which is a performance cost.

In Java code, sScreenBuff.put(sPixels) should do copying the whole buffer again.

And then, sScreenBitmap.copyPixelsFromBuffer(sScreenBuff) do it again.

So, I think the 3 times of buffer copy looks so ugly. How can I optimize those codes?

(2). After read some Android OpenGL ES related stuff, GLSurfaceView seems the best way for screen update.

Does it update the physical screen buffer directly?

(3). For GL solution, how to render a raw pixel buffer to GL surface? Where can I find some sample codes?

(4). Bitmap only offers Config.RGB_565 and Config.ARGB_4444/8888, why not RGB_888(with out alpha)?

Because my own canvas is in RGB_888, if I use Bitmap with ARGB_8888, it's very very slow due to the alpha blending.

- Eric

[Jack Palevich]

You ask a lot of good questions!

I don't have any ideas how to help here. From time to time we have considered adding APIs to Skia Bitmaps to help cut out one of these copies, but we have not done it yet.
 

(2). After read some Android OpenGL ES related stuff, GLSurfaceView seems the best way for screen update.

Does it update the physical screen buffer directly?

No, it doesn't update the screen directly. But the update is done as quickly as possible, and may be done using hardware accelleration on some devices.

(3). For GL solution, how to render a raw pixel buffer to GL surface? Where can I find some sample codes?

The short answer is: use glTexImage2D to load your raw pixel buffer into a texture, and then glDrawTexiOES to display it on the screen.

The long answer is: I guess you can read the "SpriteText" sample in the SDK. It uses Skia to render text to a Bitmap, then transfers the bitmap to an OpenGL texture, then draws the texture to the screen. You could start with that sample and change it to use the OpenGL glTexImage2D call to copy your raw pixel buffer data into an OpenGL texture.

(4). Bitmap only offers Config.RGB_565 and Config.ARGB_4444/8888, why not RGB_888(with out alpha)?

Because my own canvas is in RGB_888, if I use Bitmap with ARGB_8888, it's very very slow due to the alpha blending.

For performance reasons Bitmaps are always a power of 2 in pixel size. You might look through the Skia docs and see if there is a way of disabling the alpha blending. (I'm sorry I don't know the answer off the top of my head.)

For what it's worth most Android devices have a 16-bit-per-pixel screen, so it may be better to stick with RGB_565 if you can.

- Eric

[Eric Wang]

Thank you Jack!

Couple of days ago, I was studying the SpriteText sample, but the complexity of GL frustrated me, so I turned into the simpler way by using Bitmap/Canvas.

Guided by your help, I will re-study the SpriteText to understand it totally and rewrite my code by GL.

Thank you Google guys, learned so much!

2009/10/17 Jack Palevich <jac...@google.com>