xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 8 years ago

Last modified 6 months ago

#468 closed defect

Resizing with opengl=on behaves erratically — at Version 1

Reported by: alas Owned by: alas
Priority: major Milestone: 0.11
Component: client Version: trunk
Keywords: opengl re-sizing Cc:

Description (last modified by Antoine Martin)

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 (1)

comment:1 Changed 8 years ago by Antoine Martin

Description: modified (diff)
Milestone: 0.11
Owner: changed from Antoine Martin to alas

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:

  • 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

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:

  • can you provide screenshots? (may not be easy..)
  • do the win32 builds support transparency? (see ticket: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?


Note: See TracTickets for help on using tickets.