Process delay of the eglCopyBuffer() .?


For Draw GDI Text in OpenGLES, I used eglCopyBuffer.

Process sequence is like that…

  1. CreatePbufferSurface().
  2. Make a Bitmap.
  3. After 3D Rendering at PBuffer, Copy PBuffer to Bitmap using eglCopyBuffer().
  4. and GDI Draw(like drawText() function) to Bitmap.
  5. last, Bitblt Bitmap to Display.

I think PBuffer data exists in video memory.
When eglCopyBuffer() is called, I guess pBuffer will move to bitmap of main memory.
I guess that It’s have a delay of the data process as long as eglCopyBuffer() be called.
Approximately, 800*480 will copy.
What do you think about that??

So I thought glDrawTexOES(). change bitmap to texture.
What is more good idea??

Can you use GDI to render directly into the visible window on the Display? If so then perhaps you could render into a window instead of a pbuffer, SwapBuffers to get the EGL color buffer contexts into the visible window, then draw GDI text into that window.

We have been discussing a proposal in Khronos that might allow a surface-to-surface color buffer copy. I’m not sure if that would be useful for your scenario but you have an interesting use case for us to discuss.

You means CreateWindowSurface()? If it’s right… I already know that.
Of course, It’s possible… but When I use WindowSurface() and SwapBuffer(). I found that GDI Text has a flickering phenomenon in the screen per frame.

How can I solve this problem??

I think the best way should be:

  • render to window surface
  • whenever the text changes (which likely won’t be every frame), draw text to a bitmap, upload bitmap as texture using glTex(Sub)Image2D.
  • render text as textured quad/with DrawTex on top of your scene.

With hardware acceleration, it is important to avoid any operations that cause synchronization between CPU and GPU. Basically, anything that accesses the current draw surface (glReadPixels, eglCopyBuffers) is bad for performance.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.