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.
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
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
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 distortedissue
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:
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.
xterm is not transparent, browsers usually aren't either (though some of their tooltips may be),
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