opengl backend should preserve fbo contents when resizing

[Antoine Martin]

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!

[Antoine Martin]

tries not to clear the textures and fbos when resizing

[Antoine Martin]

results of resizing with the noclear patch..

[Antoine Martin]

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

[Antoine Martin]

Re-scheduling.

[Antoine Martin]

Best done by someone who understands opengl better than me.

[Antoine Martin]

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

But blocked by ticket:1233#comment:3

[Antoine Martin]

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

[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.

[Antoine Martin]

@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)

[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)

[Antoine Martin]

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

[psycho_zs]

glxinfo on Intel i7-3540M

[psycho_zs]

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

[Antoine Martin]

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

[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

[psycho_zs]

Beta release debug gl_check.py

[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.

[Antoine Martin]

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

[Antoine Martin]

Done in r23332, this will help with #2217.

[Antoine Martin]

Disabled on macos: #2372

[migration script]

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