honour window gravity

[totaam]

Issue migrated from trac ticket # 2217

component: client | priority: major | resolution: fixed

2019-03-18 12:15:37: antoine created the issue

---

This should probably be honoured when we center the contents of a window because of a size mismatch.
ie: in the log sample from #2214#comment:2, using window offset values 1,3 would become 0,0 if gravity is NW.

[totaam]

2019-07-25 14:08:15: antoine changed status from new to assigned

[totaam]

2019-07-25 14:08:15: antoine commented

---

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.

[totaam]

2019-07-28 18:28:02: antoine commented

---

Updates:

• r23328 "keep track of the gravity we're supposed to honour, add env var to override the default: XPRA_DEFAULT_GRAVITY
• r23329 + r23330 + r23331: preparatory refactoring
• r23332 preserves fbos when resising (opengl backend should preserve fbo contents when resizing #478)

Still TODO: take gravity into account when copying fbo data (harder because of upside-down opengl coordinates!)

[totaam]

2019-07-29 07:55:09: antoine commented

---

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:

• ignore it (..)
• send the current server window size with all screen updates
• send the window resize counter with all screen updates, and use it to derive the window size this was for (meh)
  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.

[totaam]

2019-07-29 10:44:05: antoine commented

---

Done by exposing the window-size paint option in r23335.
r23336 makes it easier to test, ie:

XPRA_PAINT_DELAY=2000 XPRA_OVERRIDE_GRAVITY=2 python3 /usr/bin/xpra attach

Still TODO:

• fbo resizing is still slightly off (opengl viewport projection still using old dimensions? re-init first?)
• make the window-size optional? (meh)
• test on Intel chipsets.. (may need to clamp negative texture coordinates when downsizing?)

[totaam]

2019-07-29 14:33:36: antoine commented

---

Updates:

• r23338 fixes things by adding a configurable delay - no idea why we need this, looks like something in X / GLX needs to get the message about the new window size before we can present it properly.
• r23339 makes the new window-size attribute 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.

[totaam]

2019-07-29 16:41:21: antoine changed status from assigned to closed

[totaam]

2019-07-29 16:41:21: antoine set resolution to fixed

[totaam]

2019-07-29 16:41:21: antoine commented

---

Works well enough on all platforms tested, except macos: #2372 (not necessarily related)
The configurable delay should be replaced: #2373.

[totaam]

2019-08-01 17:27:14: antoine commented

---

This broke python2 - gtk2, fixed in r23396.

[totaam]

2019-08-03 04:48:55: antoine commented

---

The delayed refresh code needed to be made python2-compatible: r23400.

[totaam]

2019-08-03 08:17:01: antoine commented

---

Bug fix + ported to all backends in r23402.

[totaam]

2019-08-04 16:56:23: antoine commented

---

Disabled on macos: #2372