Open dxmaxwell opened 4 years ago
Nice, concise description! Maybe duplicate of #640?
@kasemir Yes, very concise...LOL still learning to use Github I guess.
Looks similar to #640, but I don't see the problem with x2go, only with X forwarding, and its only on Windows clients.
Any difference using GTK2 vs. GTK3? -Djdk.gtk.version=2
resp. 3?
In general, X forwarding is for us slower than 'Thinlinc' type remote-X-access in the web browser, which in turn is MUCH more convenient for MS Windows users, since there's no need to dink with installing putty and X.
@shroffk mentions a problem with X forwarding #436
As mentioned in other issues (and across the internet), I tried using various options: -Dprism.order=sw -Djdk.gtk.version=2 -Dprism.forceGPU=true
But no change. It seems to use the Software rendering by default anyway, and that works perfectly well when the client machine is Linux.
@kasemir I did not know about Thinlinc, thanks. I will look into that more, but I would need to convince the IT dept to support it.
Some comments on Java UI via X forwarding being slow are on https://stackoverflow.com/questions/26002948/workaround-for-slow-java-swing-menus, way back with Swing.
For me it helps to add ssh settings to disable compression or use a faster (less secure) encryption method, but buying Thinlinc is overall a more convenient option if you need remote access to a Linux desktop.
I'm afraid we have to mark this as "won't fix".
We acknowledge that X forwarding is slow and doesn't always work 100%.
X forwarding basically sends every drawing command over the network. That was OK back when X11 Athena Widgets only had a black rectangle around a text field. It's slow for our present reality where every widget comes with shaded outlines and backgrounds.
I can confirm that menus can take a long time (seconds) to show up when running via one or more ssh -X
hops. We have several reports of other quirks as already linked from this issue. I don't think we have a way to fix them, because the issue is in the underlying X/ssh mechanism. For example, I get the same sluggishness from "gedit" via remote-X.
If a site depends on running via remote desktops, X11-via-ssh can be used to some extend, but Thinlinc or VNC are now a better approach.
Alternatively, phoebus does build for Windows, Mac, Linux, so users can run it locally with full performance. EPICS offers CA/PVA gateways to allow (read) access to data, and we support http://.. for display access. That does of course require site support for installing CS-Studio on end user computers.
Finally, we have a web display runtime for (read) access to most display features from plain web browsers.
I think that running Phoebus locally and then using an SSH tunnel to access the desired network could work well for us. Recently I became aware of the EPICS_CA_NAME_SERVERS variable, which makes that a lot easier, do you know if JCA supports this option?
Or if Phoebus could support a SOCKS proxy for CA, that would be a very clean solution. Looks like the community has done some work in that direction, but it's still a work-in-progress.
See #988 for recently added preference setting to configure EPICS_CA_NAME_SERVERS
When displaying Phoebus remotely via X11 forwarding the menus are glitchy. Not only does the menu appear "detached" from the menu bar as shown in the screenshot below, but it is also tricky to make the menu appears. The user must click down on the menu title, then move the mouse below the menu title and release the click.
Client: Windows 10 with Putty and VcXsrv (also tried with Xming and Cygwin/X) Host: Debian Buster with a recent build of Phoebus
Note that X11 forwarding using a Linux Mint client instead of Windows10 works as expected.
From the log output it appears the UI is freezing: