This should probably be honoured when we center the contents of a window because of a size mismatch.
ie: in the log sample from ticket:2214#comment:2,
using window offset values 1,3 would become
0,0 if gravity is NW.
In some cases, but not all, we now have a widget representing the "drawing area": see r23305.
When resizing the window, we can honour the gravity when copying the backing contents over to the new one.
This would be easier to test with an env var to override the default window gravity.
Still TODO: take gravity into account when copying fbo data (harder because of upside-down opengl coordinates!)
Mostly done in r23333.
To make it easier to test with client applications that do specify a gravity (ie: xterm), we can now override it with
XPRA_OVERRIDE_GRAVITY. (also a client side switch)
One last hard problem is that whilst we're resizing the window, the server may send us window updates for the old window dimensions... Those updates will include absolute paint coordinates that are actually relative to the old window dimensions. Potential solutions:
Because of scaling and other paint transformations (delta!), it's not clear where the coordinate adjustment will need to be made.
Still todo: test with desktop scaling, video scaling, etc.
XPRA_PAINT_DELAY=2000 XPRA_OVERRIDE_GRAVITY=2 python3 /usr/bin/xpra attach
window-sizeattribute optional, also makes it possible to disable the new FBO resizing code with:
XPRA_OPENGL_FBO_RESIZE=0 xpra attach
Only testing left to do.
This broke python2 - gtk2, fixed in r23396.
The delayed refresh code needed to be made python2-compatible: r23400.
Bug fix + ported to all backends in r23402.
Disabled on macos: #2372
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2217