Android Opengl FBO offscreen
Asked Answered
D

2

7

I'm developing an Android application type finger paint. I'm using OpenGL ES 2.0. Basically I have an image where every touch screen should correspond to a circle alpha to be applied where it is shown the other image that lies beneath. I tried different techniques but are rather slow because it functions like using organic glTexSubImage2D that slow down the rendering phase. I'm trying to understand the use of FBO as they allow the off-screen rendering. Can someone explain better what it means rendering off-screen and what advantages could obtain to speed up my method?

I suppose off-screen means you can change the framebuffer created by me, out of the way onDrawFrame? In another thread?

Dehumanize answered 17/1, 2013 at 14:55 Comment(0)
A
2

In addition to being able to render into an on-screen window using OpenGL ES 2.0, you can also render into nonvisible off-screen surfaces called pbuffers (short for pixel buffer). Pbuffers can take full advantage of any hardware acceleration available to OpenGL ES 2.0, just as a window does. Pbuffers are most often used for generating texture maps. If all you want to do is render to a texture, we recommend using framebuffer objects (covered in Chapter 12, “Framebuffer Objects”) instead of pbuffers because they are more efficient. However, pbuffers can still be useful for some cases where framebuffer objects cannot be used, such as when rendering an off-screen surface with OpenGL ES and then using it as a texture in another API such as OpenVG.

[source : OpenGL ES 2.0 programming guide]

I hope this helps. Read this carefully - "pbuffers can still be useful for rendering to an off-screen surface with OpenGL ES"

Astronomical answered 20/1, 2013 at 13:27 Comment(1)
However, I have seen mention that pbuffer approach is slow on Android, due to need to switch between two EGL contexts. Instead, search for stackoverflow answers that use "framebuffer object" as the offscreen buffer.Danforth
N
0

You approach takes way to much memory bandwidth as you need to read back (part of) the screen and write back again the same amount of data back to the GPU memory. That is really slow and makes your drawing code wait before the image has been moved back to the GPU before rendering. Have you considered drawing quads for each finger press or some kind of primitive that approximate your needs? Why do you need OpenGL for this?

Nuremberg answered 17/1, 2013 at 17:6 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.