[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

Tried the Python3 builds of the Xpra 2.4 Windows client and unfortunately
it has a lot of graphics artifacts (ghosting when moving a terminal, some
applications being completely washed out and illegible, etc). I'll continue
to use the standard 2.4 build for the time being.

On Thu, Aug 30, 2018 at 11:05 AM Ben Sferrazza <bsferrazza at avnera.com>
wrote:

>
>
> On Wed, Aug 29, 2018 at 9:06 PM Antoine Martin <antoine at nagafix.co.uk>
> wrote:
>
>> On 30/08/18 07:15, shifter-users-owner at lists.devloop.org.uk wrote:
>> > Now that I've established a connection again with Xpra server 2.3.3, I
>> > can try to address some of the issues I was/am experiencing. I haven't
>> > used it enough to encounter the first two issues, which were the most
>> > debilitating and largely made it unusable for me before (the stuck focus
>> > issue and the disappearing mouse cursor). Once I can re-create those
>> > I'll have more to offer.
>> >
>> > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <antoine at nagafix.co.uk
>> > <mailto:antoine at nagafix.co.uk>> wrote:
>> >
>> >     On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote:
>> >     > Hi. I'm including my previous correspondence below, as it will at
>> >     least
>> >     > offer some history about my setup and prior issues.
>> >     >
>> >     > I stopped using Xpra a few months ago due to numerous bugs that
>> >     made it
>> >     > unusable (this is using a Linux server and Windows client).
>> >     >
>> >     > 1. windows get stuck with on-top focus
>> >     Which windows from which applications?
>> >
>> >
>> > This was by far the most egregious bug. It seemed to happen at random
>> > and affected all applications. Considering I do a lot of work in a
>> > terminal, chances are it was a terminal such as xfce4-terminal. I will
>> > report back once this occurs again. My only solution was to minimize the
>> > window, rather than simply clicking on another window to give it focus.
>> This does ring a bell, but I don't think I ever saw it myself.
>> https://xpra.org/trac/ticket/713
>> https://xpra.org/trac/ticket/1381
>>
>> This could be a platform specific bug (ie: affecting mswindows clients)
>> in which case the newer Python3 GTK3 builds may fare better.
>>
>
> Yes, those tickets describe the exact same behavior I'm experiencing (or
> at least was with Xpra 2.2) using the Windows client and Linux server. I'll
> give one of the Python3 builds a shot. Is there a particular build that you
> think would be the most stable (with the understanding that I likely need
> 2.4 and the paramiko ssh client given the tcsh issues I was experiencing)?
>
>
>>
>> >     > 2. disappearing mouse cursor when using X11-only no-toolkit apps
>> >     that use
>> >     > inverted black mouse pointer after clicking on something
>> >     Do you have a specific application we can use to reproduce the
>> problem?
>> >
>> > Unfortunately the application I encountered this issue with the most was
>> > Cadence's Simvision, a digital simulation waveform viewer that's part of
>> > their CAD/EDA software suite. The only observation I had was that it is
>> > an application which does not make use of a modern toolkit, such as GTK.
>> > Perhaps it's using Motif? When you click on a menu the mouse cursor
>> > inverts to a right-pointing black cursor, which is a cursor internal to
>> > the program and is not replaced by the client's cursor. That's when the
>> > menu items would disappear. I've attached a screenshot of it working,
>> > which required using an actual camera, as the inverted black cursor is
>> > not picked up by the Windows print screen function.
>> There were bugs in the cursor code on mswindows, including some fixed
>> quite recently, those could have caused the problems you describe - it
>> should now revert to the default cursor in case of failure.
>>
>
> OK that's great to hear. I'll keep an eye out to see if this bug occurs
> with the newer builds
>
>
>>
>> >     > 3. some windows don't show window bar until resized (e.g. gvim
>> >     always gets
>> >     > placed in upper-left without window bar)
>> >     Some applications do weird things with their geometry sometimes,
>> gvim is
>> >     one of those. That said, I've just tried it and it worked fine and
>> it
>> >     does seem to request to be placed in the top left corner.
>> >     Please provide more details so we can reproduce the window bar
>> problem.
>> >     (ie: server os and version, gvim version, etc..)
>> >
>> >
>> > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra
>> > 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT
>> > 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior.
>> > It corrects itself once I do any resizing of the window (which must
>> > initiate a redraw event). Perhaps Xpra could force a redraw event after
>> > opening the window?
>> I bet it's not a redraw event but a window "configure notification" that
>> gvim is waiting for. If I can reproduce this, it should be fixable. We
>> can synthesize an event if needed.
>> What's the server version? CentOS 7.5?
>>
>
> Actually the primary machine I use it on is CentOS 5.11 (unfortunately
> needed apparently to support an older version of Cadence IC5). Though I did
> build an entirely bootstrapped toolchain on this machine, so its using the
> latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the
> latest versions binutils and gcc. Xpra and all of its dependencies were
> built against this toolchain. However, I did just run Xpra 2.3.3 on a
> CentOS 7 machine we have here at work and with that same version of Gvim
> (8.0.586) I experience the same issue of it going to the top left corner
> and not showing the title bar until the window is resized.
>
>
>>
>> >     > 4. dialog box black bars (appears to be trying to add
>> scrollbars?).
>> >     Can you provide example applications we can use to reproduce the
>> >     problem?
>> >     I've never seen that anywhere except when X11 windows are smaller
>> than
>> >     the minimal window size on mswindows, then we have to pad it with
>> >     something.
>> >
>> > Perhaps that's all it is.
>> Sadly, it's not. From the screenshot you attached, this looks like a
>> different problem.
>>
>> > Certainly not a big deal, and just a cosmetic
>> > annoyance. I've attached an example of this issue from a dialog box that
>> > pops up using diffuse. Perhaps this would be too much work, but a
>> > slightly more pleasing visual than black bars would be to sample the
>> > color of the edge pixels and use this color (or an average of samples)
>> > to extend the window to the minimum size.
>> Fixing the problem might be easier. (it looks similar to the gvim
>> problem - the application gets the window geometry wrong)
>> Do you have a sample application I can use to reproduce it?
>>
>
> It was happening using diffuse (the graphical diff tool). If I'm comparing
> two files and edit one of them outside of diffuse, diffuse will pop up a
> dialog asking if you'd like to reload the file since it detected a change.
> That small dialog was showing the black borders. However, I'm not seeing
> the same issue again. Though there is another issue that could perhaps be
> masking this. For some reason, many of my GTK applications (diffuse, gvim,
> etc) are not using the window decorations and icons I have chosen when
> using Xpra. This was working just fine in Xpra 2.2, and the correct theme
> and icons are shown when I VNC into the same machine. Oddly enough, Emacs
> does use the correct decorations even with the latest Xpra.
>
>
>>
>> >     > 5. windows are all blank (white) when returning into work after
>> >     several
>> >     > hours (requires restarting client)
>> >     That's a known "feature" of some opengl drivers, they clear the
>> video
>> >     memory when the system goes into idle or suspended state.
>> >     We try to detect that (slowing down the refresh rate) and then
>> refresh
>> >     the screen when the session resumes, but that doesn't always fix
>> things.
>> >     You should not need to restart the client: minimizing the windows
>> and
>> >     restoring them should be enough.
>> >     Alternatively, turn off opengl in the client - the client
>> performance
>> >     will be much lower.
>> >
>> >
>> > OK, the next time this occurs I'll try to simply minimize the windows.
>> >
>> >
>> >     > 6. flickering clipboard icon in systray
>> >     That's a very obvious sign that something is not right and
>> something is
>> >     constantly requesting the clipboard contents. This will cause
>> >     unnecessary traffic and instability. Try to figure out what is
>> causing
>> >     this and stop it. Usually, this is caused by clipboard managers or
>> other
>> >     clipboard synchronization tools (synergy, virtualbox, etc).
>> >
>> >
>> > Hmm. I don't have anything running like that. No VNC session,
>> > VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly
>> > nothing is currently connected to it. It seems to flicker at a rate of
>> > once every 4 seconds or so.
>> OK, then it's not so bad that it will cause instability.
>> Some clipboard managers request the clipboard contents as soon as
>> they're available, swamping the system with clipboard events.
>> If you wish, you can confirm the rate of change by running the client
>> with: "--debug=clipboard"
>>
>> > It seems periodic, in the mathematical sense
>> > of the word. My PC at work is a standard issue Dell box. It has the
>> > typical Dell bloatware and some Symantec security software (not much
>> > control over this), but can't think of anything that could be
>> > potentially interfering with the clipboard. Any suggestions how to
>> > determine the cause?
>> Sorry, I don't know how. The API we use to interact with the clipboard
>> does not offer any information about the application which set or
>> queried the clipboard. Some third party tools may exist to monitor the
>> system at this level.
>>
>
> Is there a way to turn off the flickering, just to avoid the annoyance of
> it? Also, it seems the newer versions of Xpra place a small Xpra icon
> imposed on top of a window's regular icon. Is there a way to turn off this
> feature, as it's difficult for me to see the original icon, since it's
> resized smaller.
>
> Thanks,
> Ben
>