Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 3 of 3 FirstFirst 123
Results 21 to 21 of 21

Thread: Lock the Default Framebuffer

  1. #21
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    590
    I don't want to do a copy operation. And with SwapBuffers, you don't have to. Why should we accept that (likely minor) performance penalty even when we don't use it? Why not get the best of both worlds: the ability to talk directly to default framebuffer images, and the ability to get the fastest buffer swapping performance possible.
    Um, err... under X11 with a compositing window manager the situation is quite, quite ugly. For X11 the incantantation is this, and I joke you not:
    1. Create a pixmap from the window handle (this may or may not be a copy operation, depends)
    2. Create a GL texture from the pixmap (this is not a copy usually, usually it is texture from pixmap)
    3. draw the GL texture


    This sequence is executed _each_ freaking frame, not just startup or when a window is made, but each and every freaking frame. In theory an optimized X11 system may make it so that the "pixmap" is not created each time, but such a scheme either requires that the application is blocked by the compositor or that somehow some triple buffering is going on.... often enough, the contents of the window's front buffer might be copied to the pixmap.... one can argue that vsync means blocked by the compositor but not really, it is messier than that. On a related note, X11/EGL is a cesspool, as EGL you set the color buffer bits, and X11 window does too.... so crazy the world is that for most paltforms if the bits don't match, you get an EGL error, but there was an extension for Tegra that had it convert that which you renderer to whatever format the window was, the extension was EGL_NV_post_convert_rounding (you can see it in use for example in Qt code: http://qt.gitorious.org/qt/qt/blobs/...l/qegl_x11.cpp )

    Fullscreen is a different matter, but under X11, a window is fullscreen or not is actually really a message/flag the compositor sees and decides, at it's leisure, to obey.

    But back to l_belev(not Illian ) on paper the window's framebuffer could change all the time _IF_ the machinery of pixmap and texture from pixmap took into account various color formats.. but AFAIK, all that is really available is RGB565, RGBA8 and RGB8 for X11 pixmaps....

    Other windowing systems around are Android's, iOS, Windows... iOS already does the render buffer thing, but it means that an application is NOT double buffered, rather there is an iOS call that says "present the renderbuffer [possibly at vsync]". Android uses EGL, but I don't remember/know what the Android platform does with respect to windowed stuff ... for fullscreen, it likely is just simple double buffering....
    Last edited by kRogue; 09-11-2012 at 01:04 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •