Resizing opengl windows behaves erratically (transparency issue)

[totaam]

Issue migrated from trac ticket # 468

component: client | priority: major | resolution: fixed | keywords: opengl re-sizing

2013-12-11 01:31:01: afarr created the issue

---

Testing with osx 0.11.0-4905 and with win 0.11.0-r4903, with opengl=on (default), resizing the windows creates erratic behaviors.

With win client, the window shifts to a sort of magenta while the screen is redrawn. With osx the contents of the window become distorted and remain so, with elements distorted, shifted, and often unintelligible.

Tests with previous clients (osx r4855, win r4839) connecting with the same server (fedora 19 0.11.0-r4904) the behavior is as expected.

Is there a debug mode that will produce specific information that would be of use? Some debugging output that should be grepped for in particular? Would a screenshot of the especially erratic osx resizing results be of use?

[totaam]

2013-12-11 05:51:07: totaam changed owner from antoine to afarr

[totaam]

2013-12-11 05:51:07: totaam edited the issue description

[totaam]

2013-12-11 05:51:07: totaam commented

---

This is probably all caused by r4880, so maybe this info should have been added to #385.
Reverting r4880 is not really a good solution: we don't want to special case transparent windows, and GPUs store pixel data as 32-bit RGBA anyway.

I have no such problems on Linux (tested with "nvidia" driver), and my OSX and win32 virtual machines do not support opengl... so I cannot test.

The client debugging switch for OpenGL is XPRA_OPENGL_DEBUG=1, but it is highly unlikely to provide any useful information in this case.

[[BR]]

---

So here is what I found through code inspection only:

• r4913 should fix the the window shifts to a sort of magenta while the screen is redrawn
• Either r4914 or r4915 (or both) should fix the window become distorted issue

[[BR]]

I believe the problem was caused by the alpha blending code.
And on some cards+drivers, when the alpha channel is unused it is zeroed (linux) but with others it seems to contain random junk (osx, win32).

[[BR]]
Important: because of the changes in r4915, you now need to test using a window that uses transparency to ensure that the issue really is fixed. As non-transparent windows now skip alpha blending altogether.

[[BR]]

---

If there are still issues to do with smearing/resizing redraws, please provide more details as appropriate:

• can you provide screenshots? (may not be easy..)
• do the win32 builds support transparency? (see opengl rendering improvements: handle plain RGB, scaling, transparency #385#comment:17 for testing) - I don't think they can as this is a GTK2 limitation.
• on osx, does this also happen with windows that have transparency (see above) or just with non-transparent windows (ie: xterm)?
• does changing the encoding make any difference?
• does minimizing then restoring the window help?
• what difference does each patch make?
  etc

[totaam]

2013-12-12 02:36:26: afarr commented

---

With win client 0.11.0-r4928 with --opengl=on the re-sizing is a little "jittery" but otherwise seems fine (to me... anyone expecting absolute smoothness may be disturbed, but I don't even see that with locally running applications). It seems to behave about equally smoothly whether with an xterm or a chrome browser window. (I'm not certain I'm understanding you right about the transparency issue. The xterms I get on win client have a border which, when I started mussing with windows display options to make transparency glaringly eye-catching, seemed as obviously transparent as the chrome windows.)

With osx client 0.11.0-r4928 with --opengl=on the re-sizing behaved perhaps a tiny bit more "jittery" than the win client, but generally seemed fine- whether an xterm or a chrome window.

If there's a particular application whose transparency you would like tested, let me know. Otherwise, I think this is solved (until someone tells me that even a little "jitter" is unacceptable).

[totaam]

2013-12-12 05:46:04: totaam changed title from Resizing with opengl=on behaves erratically to Resizing opengl windows behaves erratically (transparency issue)

[totaam]

2013-12-12 05:46:04: totaam commented

---

the re-sizing is a little "jittery" but otherwise seems fine
[...]
the re-sizing behaved perhaps a tiny bit more "jittery" than the win client
Is this a regression? How is this related to this ticket?

[[BR]]

I'm not certain I'm understanding you right about the transparency issue
You need a transparent application. An application whose window contents is at least partially "see-through". The borders of the application have nothing to do with xpra: those are drawn by the client OS.

[[BR]]

For example: xterm is not transparent, browsers usually aren't either (though some of their tooltips may be), gnome-terminal and mate-terminal can be configured to be transparent, the test application I linked to in comment:1 definitely is: [/browser/xpra/trunk/src/tests/xpra/test_apps/transparent_colors.py tests/xpra/test_apps/transparent_colors]

[[BR]]

As per comment:1, you are unlikely to see any transparency on win32 with or without opengl, and it may work on OSX - though it does not in my VM.
It should work fine on other *nix-like platform in pretty much all cases.

[totaam]

2013-12-13 14:34:07: totaam commented

---

Since transparency is also problematic on OSX, r4934 disables it.

What I really want to know is if the "erratic resizing" is a regression or not.

[totaam]

2013-12-13 18:05:17: afarr commented

---

I don't think it's a regression. Just a bit of jitter when resizing with opengl.

That said, I guess this ticket can be closed.

[totaam]

2013-12-14 01:20:47: totaam changed status from new to closed

[totaam]

2013-12-14 01:20:47: totaam changed resolution from ** to fixed