Recent changes to feature-requests

#10 H.264 encoding support for TurboVNC

DRC — Sun, 06 Aug 2017 21:05:54 -0000

This SF tracker item is quite old and doesn't reflect the current thinking regarding the H.264 feature. It is still under active investigation:

https://github.com/TurboVNC/turbovnc/issues/19

There are definitely some workloads that benefit from H.264. There are others that don't. The report attempted to compare performance based on some assessment (albeit probably a weak one) of image quality equivalence, and without knowing the specifics of how you performed your comparisons, I cannot speak to your findings. You might not be comparing apples to apples. Xpra is using a different protocol than we are, and whereas our RFB implementation includes extensions that provide better performance on high-latency networks, it's entirely possible that Xpra's protocol does a better job of flow control on extremely low-bandwidth links. Or it may simply be that their protocol is a better fit for your specific workload. Benchmarking is something of a dark art, and you always have to be very careful when making any kind of general assumption based on it. Really, a single benchmark cannot tell you much outside of the specific scope in which it was run.

That being said, I haven't given up on H.264. I have only given up on a software-based H.264 solution, since that is definitely too compute-intensive to be of use in TurboVNC. What I'm looking at now is using NVENC on the server, but there are a lot of problems inherent in that, as described in the GitHub issue. Ultimately, this may have to be deferred until Wayland becomes more of a thing, since Wayland would make the use of a frame-based codec like H.264 much more straightforward. Note that Xpra, by virtue of using a window-based protocol instead of a screen-based protocol like RFB, also has an easier time leveraging H.264 than any VNC solution would. VNC is, ultimately, a remote desktop solution rather than a remote application solution, and the way X11 interacts with the remote framebuffer makes frame-based codecs an awkward fit at best.

#10 H.264 encoding support for TurboVNC

Reimar Döffinger — Sun, 06 Aug 2017 20:39:31 -0000

I can't say what the cause might be as the write-up seems solid, but from practical experience the conclusions drawn from that analysis seem simply wrong.
Using VNC (client makes only marginal difference) is frustrating and a pain over a low-bandwidth DSL connection (approx. 1 MBit/s) while it works comfortably using Xpra (after disabling lossless refresh), which uses H.264.
It is usable (much better than VNC, though still not nice to use) even when connecting to a Cubieboard (ARM-based, Cortex-A7).
Obviously a big VNC server has other requirements, as well as users needing accuracy and thus lossless refresh, but for personal use I haven't found a solution (VNC, x2go, RDP - TeamViewer maybe) that seems even just competitive to Xpra in real-use comfort for tasks like web browsing remotely, and maybe it would be worth checking what causes the discrepency with this report.

#30 A dropdown toolbar when in fullscreen

DRC — Sun, 21 Aug 2016 14:57:11 -0000

Gregory, the SourceForge trackers are closed to new issues for a reason-- because I want people to post new questions on GitHub, not here. It is inappropriate to ask a new question in the comment section of an old tracker item.

#30 A dropdown toolbar when in fullscreen

Gregory — Sun, 21 Aug 2016 13:54:29 -0000

hi, plz tell me how to use repeater (ultravnc) in turboVNC

Features/fixes introduced in 2.0 beta1:
[12]
vncconnect can now be used to connect a TurboVNC Server session to an
instance of the UltraVNC Repeater in Mode II.

#30 A dropdown toolbar when in fullscreen

DRC — Fri, 05 Aug 2016 15:37:03 -0000

status: open --> closed

#30 A dropdown toolbar when in fullscreen

DRC — Fri, 05 Aug 2016 15:36:48 -0000

Moved to GitHub
https://github.com/TurboVNC/turbovnc/issues/45

#27 Clipboard toggle button and hotkey

DRC — Fri, 05 Aug 2016 05:05:57 -0000

status: open --> closed-implemented

#27 Clipboard toggle button and hotkey

DRC — Fri, 05 Aug 2016 01:13:27 -0000

Yes, that's also expected, because clipboard synchronization occurs in both directions. When the remote clipboard changes in Session 1, the change is synchronized to your local TurboVNC Viewer instance, which changes the clipboard on your machine, then the other TurboVNC Viewer instance detects the change and synchronizes it to the remote clipboard in Session 2. Bear in mind that TurboVNC was designed for running high-performance 3D and video applications remotely, not for monitoring multiple users, so your workflow is very non-standard. In most use cases, this behavior is desirable, because the users want to be able to seamlessly copy/paste between their local desktop and the remote desktop.

The Java viewer has two settings, one for disabling inbound clipboard synchronization and the other for disabling outbound. The Windows viewer, for historical reasons, only has one setting for disabling all clipboard transfers.

I'll go ahead and implement this as a separate hotkey (CTRL-ALT-SHIFT-C.)

#27 Clipboard toggle button and hotkey

Dan — Thu, 04 Aug 2016 21:26:08 -0000

Yes, the clipboards still sync in view-only mode.
The flags are independent of one-another in the setup screen, ie. enbling the view-only flag doesn't disable the clipboard flag.
Perhaps something to address at if you plan to disable clipboard syncing when view-only is enabled.
Personally, I prefer them to be independent, as sometimes I pass (or receive) information via the clipboard to a view-only session, but it won't be a bother if you decide to change it.

Thanks,
Dan

#27 Clipboard toggle button and hotkey

DRC — Thu, 04 Aug 2016 20:59:41 -0000

Does this still happen if you're in view-only mode? I think that perhaps a cleaner way to address this would be to stop syncing the clipboard in view-only mode, and I thought the viewer already did that. If it doesn't, then I think it should.