xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 7 years ago

Last modified 5 months ago

#679 closed enhancement

opengl improvements: double buffering, limited repaints, paint state — at Version 4

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 0.16
Component: client Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

See also ticket:640#comment:3.

At the moment, only win32 uses double-buffering by default.
Is it required? Useful? The PBO is a bit like our own double buffering already.
Does double buffering limit the number of paints we can do per second because of the synchronization that happens when we swap_buffers? (if there is any!)
This can also cause problems if we have many windows: they will all consume synchronization time. Or will they? See Swap buffer synchronization and Using SwapBuffers() with multiple OpenGL canvases and vertical sync?

This needs testing with:


And maybe a dedicated test app to trigger the paint refresh pattern needed for testing. (many windows? fast refresh? hard!)

Same for Linux, do we want to enable double buffering there?
Does it work reliably? (works here)

Also, when not using double buffering, we can optimize repaints to only paste the fbo contents on the area of the window that needs updating instead of the whole window.

As per http://www.mesa3d.org/brianp/sig97/perfopt.htm: SwapBuffer? calls and graphics pipe blocking: On systems with 3-D graphics hardware the SwapBuffers? call is synchronized to the monitor's vertical retrace. Input to the OpenGL command queue may be blocked until the buffer swap has completed. Therefore, don't put more OpenGL calls immediately after SwapBuffers?. Instead, put application computation instructions which can overlap with the buffer swap delay.
See also http://www.opengl.org/wiki/Swap_Interval
We should try to ensure we don't make any GL calls after swap_buffers.
For example, the whole set_rgb_paint_state / unset_rgb_paint_state logic should be changed to be done on-demand before each paint rather than assuming a specific state is the default. There is also a glClear there, not sure what to do with it: it doesn't really do anything, but I can only find conflicting information on the performance implications.

Also, we want zerocopy upload for video encodings, especially dec_avcodec2, see #717 - currently disabled because avcodec buffers are not thread safe?

Change History (4)

comment:1 Changed 7 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned
Summary: opengl improvements: double buffering, limited repaintsopengl improvements: double buffering, limited repaints, paint state

comment:2 Changed 7 years ago by Antoine Martin

Description: modified (diff)


  • r7600 + r7608: only repaints what is needed in single-buffer mode
  • r7601: paint debugging via XPRA_OPENGL_PAINT_BOX env var
  • r7603: removes the glClear after swap_buffers

No matter how many small glxgears window I start, I seem to only get ~60fps, which is my monitor refresh rate... So we are capped.

Whilst we're here, it would be good to deal with #478 too.

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 7 years ago by Antoine Martin

r7600 caused #693: bug with scaling, which is fixed in r7804.

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 7 years ago by Antoine Martin

Description: modified (diff)

#717: bug caused by old versions of pyopengl found in Fedora 20..

Note: See TracTickets for help on using tickets.