• Locked Locked
  • Replies 3 replies
  • Subscribers 136 subscribers
  • Views 6204 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

eglCopyBuffers() issue.

Gaetano Montalti
Note: This was originally posted on 4th June 2012 at http://forums.arm.com

[font=arial][size=2]Hi,[/size][/font][font=arial][size=2]In my project I am using egl library to plot a 3D object to the display and concurrently saving the image in a file or an area of memory.[/size][/font][font=arial][size=2]I'm trying to use eglCopyBuffers()  to copy a surface to a pixmap  in order to obtain the pixel value that are displayed. I'm using an ARM MALI architecture and I would not want to use X11 but writing directly to GNU/Linux framebuffer.[/size][/font][font=arial][size=2]I have few questions:[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]1)In my method, I pass to eglCopyBuffers function,  as 'native_pixmap' parameter, an 'EGLNativePixmapType native_pixmap= NULL'. Is it correct? How should I declare the pixmap if I do not want to use X11 libraries?[/size][/font][font=arial][size=2]In addition, if I do as above, eglCopyBuffers returns an EGL_FALSE error, which means that the swapping of the surface buffers fails. [/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]2) Is there another simpler method to obtain the image displayed in framebuffer? Should I directly read data from /dev/fb0? I read about the method glReadPixel but it is described as being slow and X11 dependent.[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]Thank you in advance for your advice.[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]Kind Regards,[/size][/font][font=arial][size=2]Gaetano[/size][/font]
Parents
  • Note: This was originally posted on 4th June 2012 at http://forums.arm.com

    [font=arial][size=2]
    [/size][/font][font=arial][size=2] I read about the method glReadPixel but it is described as being slow and X11 dependent.[/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It's not X11 dependent; it's a standard part of the OpenGL ES API. [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It is however generally slow. It is worth nothing that for most hardware-based graphics almost any form of readback is slow, so this issue is not unique to read pixels. For "typical use" the CPU never touches the rendered image; it is rendered, composited with other windows, and displayed on screen all using different hardware blocks. Most graphics architectures exploit this fact to improve efficiency, but in consequence forcing things back on the CPU can cause stalls in the processing pipeline.[/size][/font]


    Reading back from /dev/fb0 may be faster, as far as you can bypass the graphics pipeline issues, but you have to sync up what in in the framebuffer with a specific application frame (and hope it isn't overwritten by the _next_ frame - remember the hardware rendering is asynchronous to the application calls).


    HTH,
    Iso


    [font=arial][size=2]
    [/size][/font]
Reply
  • Note: This was originally posted on 4th June 2012 at http://forums.arm.com

    [font=arial][size=2]
    [/size][/font][font=arial][size=2] I read about the method glReadPixel but it is described as being slow and X11 dependent.[/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It's not X11 dependent; it's a standard part of the OpenGL ES API. [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It is however generally slow. It is worth nothing that for most hardware-based graphics almost any form of readback is slow, so this issue is not unique to read pixels. For "typical use" the CPU never touches the rendered image; it is rendered, composited with other windows, and displayed on screen all using different hardware blocks. Most graphics architectures exploit this fact to improve efficiency, but in consequence forcing things back on the CPU can cause stalls in the processing pipeline.[/size][/font]


    Reading back from /dev/fb0 may be faster, as far as you can bypass the graphics pipeline issues, but you have to sync up what in in the framebuffer with a specific application frame (and hope it isn't overwritten by the _next_ frame - remember the hardware rendering is asynchronous to the application calls).


    HTH,
    Iso


    [font=arial][size=2]
    [/size][/font]
Children
No data