Testing with osx 0.11.0-r4905 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?
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.
So here is what I found through code inspection only:
the window shifts to a sort of magenta while the screen is redrawn
window become distorted issue
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).
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.
If there are still issues to do with smearing/resizing redraws, please provide more details as appropriate:
etc
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).
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?
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.
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: tests/xpra/test_apps/transparent_colors
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/468