#468 closed defect (fixed)
Resizing opengl windows behaves erratically (transparency issue)
Reported by: | alas | Owned by: | alas |
---|---|---|---|
Priority: | major | Milestone: | 0.11 |
Component: | client | Version: | trunk |
Keywords: | opengl re-sizing | Cc: |
Description (last modified by )
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?
Change History (7)
comment:1 Changed 7 years ago by
Description: | modified (diff) |
---|---|
Milestone: | → 0.11 |
Owner: | changed from Antoine Martin to alas |
comment:2 Changed 7 years ago by
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).
comment:3 Changed 7 years ago by
Summary: | Resizing with opengl=on behaves erratically → Resizing opengl windows behaves erratically (transparency issue) |
---|
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.
comment:4 Changed 7 years ago by
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.
comment:5 Changed 7 years ago by
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.
comment:6 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/468
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
GPU
s store pixel data as 32-bitRGBA
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
isXPRA_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
issueI 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