[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

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