Xpra: Ticket #478: opengl backend should preserve fbo contents when resizing

At the moment, when we change the size of the backing, we do an almost full gl_init() which clears the textures and fbos. This makes the screen flicker a little because we have to wait for the next frame before we can paint the actual contents, unlike the pixmap backing which paints the old backing contents onto the new one.

A patch is attached which detects screen size changes and tries to avoid clearing the buffers, but this leads to buffer bleeding on the edges of the old dimensions!? (screenshot also attached)

Another thing we should be able to do is to paint both the fbo and the backbuffer at the same time, instead of painting onto the fbo then doing a full update of the backbuffer from the fbo using present_fbo. Or at the very least, we should pass the coordinates of the region to paint rather than painting the whole window!

Wed, 18 Dec 2013 08:34:44 GMT - Antoine Martin: attachment set

tries not to clear the textures and fbos when resizing

Wed, 18 Dec 2013 08:35:44 GMT - Antoine Martin: attachment set

results of resizing with the noclear patch..

Mon, 20 Jan 2014 11:15:06 GMT - Antoine Martin: owner, status changed

Wed, 19 Mar 2014 08:38:42 GMT - Antoine Martin: priority, description, milestone changed

Too late for 0.12, but important so raising the priority.

Sat, 17 May 2014 11:15:39 GMT - Antoine Martin: milestone changed


Wed, 22 Apr 2015 04:01:25 GMT - Antoine Martin: milestone changed

Best done by someone who understands opengl better than me.

Wed, 22 Jun 2016 08:22:25 GMT - Antoine Martin:

This should be easier now that we have code that swaps framebuffers: r12878

But blocked by ticket:1233#comment:3

Thu, 30 Jun 2016 18:33:49 GMT - Antoine Martin: attachment set

try to use blitframebuffer and the tmpfbo to preserve the contents - no workee

Fri, 08 Jul 2016 06:15:45 GMT - psycho_zs:

Is this related to window resizing? with latest 0.18 build window content is visually shifted and shredded when resizing with opengl switched on.

Fri, 08 Jul 2016 16:06:44 GMT - Antoine Martin: owner, status changed

@psycho_zs: it is, can you check if the shredding still occurs if you run the client with XPRA_SCROLL_ENCODING=0 xpra attach ... or with opengl turned off? (see #1232 for details)

Fri, 08 Jul 2016 18:10:18 GMT - psycho_zs:

No shredding with opengl turned off. still occurs with XPRA_SCROLL_ENCODING=0 on client side. (xpra 0.18.0, beta package of 2016-06-28)

Tue, 02 Aug 2016 10:11:19 GMT - Antoine Martin:

@psycho_zs: can you please post your gl_check (or even the full bug report zip)?

Tue, 02 Aug 2016 10:16:02 GMT - psycho_zs: attachment set

glxinfo on Intel i7-3540M

Tue, 02 Aug 2016 10:17:41 GMT - psycho_zs:

is that what you've asked, or you mean something from xpra debug output?

Tue, 02 Aug 2016 10:20:48 GMT - Antoine Martin:

@psycho_zs: see wiki/ClientRendering/OpenGL: python xpra/client/gl/gl_check.py

Tue, 02 Aug 2016 10:29:33 GMT - Antoine Martin:

* renderer                        : Mesa DRI Intel(R) Ivybridge Mobile
* vendor                          : Intel Open Source Technology Center

The Intel drivers don't work properly and should have been greylisted by the gl_check code. @psycho_zs: can you run with the latest beta build with:

XPRA_OPENGL_DEBUG=1 python xpra/client/gl/gl_check.py

Tue, 02 Aug 2016 10:32:33 GMT - psycho_zs: attachment set

Beta release debug gl_check.py

Tue, 02 Aug 2016 10:34:35 GMT - Antoine Martin:

@psycho_zs: that's now correct and shows:

* safe                            : False

And opengl will not be enabled by default with this Intel card (more info here: #1233), the visual corruption should disappear.

Wed, 28 Mar 2018 05:47:11 GMT - Antoine Martin: owner, status, milestone changed

Not heard back, so I assume that the corruption is fixed.

Sun, 28 Jul 2019 17:26:28 GMT - Antoine Martin: status, milestone changed; resolution set

Done in r23332, this will help with #2217.

Sun, 04 Aug 2019 15:56:25 GMT - Antoine Martin:

Disabled on macos: #2372

Sat, 23 Jan 2021 04:56:48 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/478