PBuffer example on teh SDK not right!!!

[abolfoooud]

Hi,

I managed to build the SimpleCubePbuffer example provided with the SDK (3rd FP1) and run in on an N95. However i noticed something weird in this example.

I suppose that with a pbuffer all OpenGL rendering will take place on top of this buffer serface (on top of whatever content it has), correct me if am wrong. In the example we see the creation of a CWsBitmap object with is constructed then created using CreateL, which should generate an empty bitmap filled with white color. Then in the DrawwCallBack function this bitmap is filled using eglCopyBuffers and then rendered to screen using BitBlt in Draw().

Now when u run the example you notice that the cube is drawn on a black background RATHER than white!! Also, when u run the application you notice a background flicker white color before the cube is drawn. This flicker is actually the initial content of the CWsBitmap object before it has been replaced via eglCopyBuffers. I tried creating an CFbsbitmap containing some image and it appeared first before the cube and the black background are displayed.

So, what is wrong in here? Shouldn't the OpenGL drawing be placed on the white background, or the image i used? If that is the case, how can we know the correct way of using the PBuffer? Can we have another example please ?

regards
AF

[Flame]

Hi.

eglCopyBuffers() copies the GL (back) color buffer to the target bitmap replacing all of the pixels there (bitmap size == color buffer size). So, none of the content of the original bitmap should be there after the eglCopyBuffers() returns.

If you want to fill the background with white, you should call:

glClearColor (1.f,1.f,1.f,1.f);
glClear (GL_COLOR_BUFFER_BIT);
eglCopyBuffers ( .... );

Jani Vaarala
Graphics Architect
Nokia

[abolfoooud]

Thanx Jani for your reply.
Why should i use eglSwapBuffers()?? I thought this is not necessary for pbuffer and pixmap surfaces! Also it is not present in the code of SimpleCubePBuffer.

I do not want to fill the background with white color. that was just my observassion when loading empty bitmap. what i really need is applying the openGL drawing on an image in the background, and that image shall change constantly (that is why i am not using window surface). I did this before with pixmap, but it is not supported on N95 now :S

besides, there is something i do not get in your code snipet. How can i fill the background with white while passing red value to glClearColor (is that a typo)?

cheers
AF

[abolfoooud]

Is there are other way that i can use to superimpose gl on top of a background image that changes regularly? (In case pbuffer does not do the job)

[Xmas]

You can upload the image as a texture, then render a quad with that texture as background. What kind of background image are you using?

[abolfoooud]

I do not think that this is a practicle solution. I will be feeding images from teh camera in each frame. I read in one of the threads here that using window surfaces, where i load the images as textures, is not recommended in this scenario as there is alot of overhead (loading, buffering, storage, etc.). It was recommended to use pixmap or pbuffer surfaces.

The thing is i managed to do this in the past on gl 1.0 using pixmap. nu now since this feature is not implemented in N95 GL 1.1 i can not use it. I am trying pbuffer instead...but apparantly there is something wrong there...

thanx for the reply by the way

[serg3d]

Are you doing some Augmented Reality stuff abolfoooud ?
I'm interested in the answer too. I'm running my code on 7.0s now, using pixmap, and was thinking about porting to 3rd FP1. However if video background in 3rd edition is impossible or too slow it could be a major stambling block. I already heared of this problem on N95, would like to know if there is a solution before starting to port.

[miguelbl]

Its perfectly possible to update the opengl rendering witha texture coming from the camera. It is fast enough and it is the best solution in your case.

You render a quad with the camera image as a texture and then render any other object on top of it. Then you display it on the screen or you use a pbuffer to get it offscreen to a bitmap.

I still cannot understand what is the problem here.

[abolfoooud]

Seg3d,
yes i am doing some sor of augmented reality, though i am still in the first stages

miguelbl,
I am not worried about texture at th moment. this is not the solution am after actually. I wanted to use the like-pixmap solution as it is neater, managable and simpler. I thought pbuffer would do teh same job, shouldn't?

AF

[miguelbl]

A pbuffer is a buffer like the screen (but of an arbitrary size and rendered without being shown on it).

It will give you the same that you would have on the screen if rendering to it, so the background color will be present.

When you copy the pbuffer into a bitmap, you fill the bitmap with the result of the pbuffer, so if the background is black, it will be filled with black. What you need is to render to something that is "transparent" excepting the object that you want, so you can use the image of the camera as a background. Well, as far as I know, this is not possible, so your only chance is to import the camera image as a texture, render with openGL and get it back as a pbuffer (or on the screen).

So for an augmented reality program, if you want to render with openGL (mixing openGL and native graphics) you have either to render the camera image or dealing with the bitmap that is result of eglCopyBuffers() that WILL have the already set background color because is just the openGL render.

Pixmap surface are not implemented because with a HW-accelerated device it is not possible to "accelerate" it as easily.

I hope I have explained myself well. Anyway, there are some threads were the user "Flame" explains this in a more clear way than me.

BR,

Miguel

[abolfoooud]

thanx for this Miguel. U have explained it very well
I just don't know why nokia has done this to us why to remove pixmap and not provide an alternative :S apparantly pbuffer is not the exact alternative.

any ways, i will try using this texture thingy and see.

thanx again
AF

[miguelbl]

why to remove pixmap and not provide an alternative
AF

Because it is not possible to HW-accelerate such a thing. It is basicaly a HW matter. Even pbuffer is slower than rendering to the screen. I am pretty sure that in no HW-acceleration devices it is still possible to use pixmap.

BR

Miguel

[Flame]

About the eglSwapBuffers().. that was a typo. As was the clearcolor (yes it was red). I corrected them to the original response.


In the EGL specification basicly all of the rendering surfaces are optional. Pixmap surfaces are tricky to HW accelerate (at the moment) so those are not supported in HW accelerated devices. Probably the best solution would have been to NOT expose pixmap surfaces at all (in the SW OpenGL ES implementation) so that the applications couldn't depend on those.

In your application area the best (meaning: best performance) way is to use window surfaces (that generally give 2-3x boost in performance over pbuffer rendering as they can target the screen directly without the extra cost of pbuffer + copybuffers + bitblit that you would have to do otherwise and the associated CPU-GPU synchronization that comes from that).

As the pixmap surface is not supported, the only way really is to use texture upload anyway -> better use the window surfaces for the optimal performance. When implementing the texture upload, please check the document "Best practices for HW accelerated graphics optimization" in Forum Nokia as it gives some insights on how to make that run as fast as possible (minimizing CPU-GPU synchronization etc.).

There may be one way to do this in the similar way as you did before:

- setup a pbuffer render surface
- fill background transparent black (0x00000000) with glClear( )
- render 3D stuff with GL
- call eglCopyBuffers() to a EColor16MA target bitmap (newer devices)
- bitblit it with blending to your another bitmap (where your original
background is)

This might work, but it is probably N times slower than the window surface + texture upload approach.

Jani Vaarala
Graphics Architect
Nokia