There is no Windows server.  We had one at one time that was based on 
the old TightVNC 1.3 version of WinVNC, with the codec and encoding 
methods replaced by those in TurboVNC.  However, there were a lot of 
known issues with the TightVNC 1.3 Windows Server code base, so the 
TurboVNC Windows Server was really buggy and borderline unusable. 
Constantin moved to a completely different code base with TightVNC 2.0, 
so all of those issues have been resolved, but the TightVNC 2.0 codec is 
still very slow, and it would take probably a 100-hour effort to 
overhaul it in the same way that I originally overhauled the TightVNC 
1.3 codec.

In the context of running 3D apps, there has been little demand for us 
to develop our own WinVNC flavor, because we already have a better 
solution for Windows 3D apps:  running them in a VirtualBox virtual 
machine inside of VirtualGL inside of TurboVNC on Linux (see VirtualGL 
User's Guide for tips on how to do this.)  There is some overhead to 
this solution, since each user is getting their own virtual Windows box, 
but it offers the best user experience at the moment, and it allows you 
to serve up multiple simultaneous Windows apps from the same server and 
share the GPUs with VirtualGL much like you do currently with Linux 
apps.  Some customers have had success with running WINE in VirtualGL as 
well-- how well (or if) that works depends on the app.

Serving up 3D apps from a "native" Windows server is a tricky 
proposition.  The Windows VNC server (WinVNC) doesn't work the same way 
that Unix VNC servers work.  The Unix VNC server functions as a kind of 
virtual display, but WinVNC is instead a screen scraper.  It sits on the 
"root" display of the Windows box and is able to transmit only the
pixels from that display.  Thus, only one user at a time can log in and 
use the box to run 3D apps.  A solution using the TurboVNC Server for 
Windows was proposed while I was at Sun, and we developed a proof of 
concept for it in the 2007-2008 timeframe.  The basic concept was 
similar to HP RGS for Windows.  A simple interposer sat under the OpenGL 
app, similar to what VirtualGL does on Linux, but its job was only to 
redirect the rendering into a Pbuffer, read back the pixels, and then 
display them to the application window.  Since the hardware-accelerated 
3D rendering commands typically bypass the GDI layer, most screen 
scrapers (WinVNC, LiveMeeting, GoToMeeting, etc.) cannot pick up the 3D 
rendering area of Windows applications, or they will not detect when the 
3D area has been updated.  Our simple interposer solved that problem, 
because, like VirtualGL, it converted the 3D rendering into a simple 
stream of image drawing commands that the screen scraper could detect. 
However, this created another problem.  A "dumb" screen scraper reads 
back the pixels directly from the graphics card prior to compressing and 
sending them to a client.  So, now the application would render into a 
Pbuffer on the graphics card, the interposer would read back the pixels 
into memory, the interposer would display the pixels back to the 
graphics card, then WinVNC would read the pixels back yet again.  Thus, 
the pixels traversed the bus three times.  The use of a mirror display 
driver would have helped, since this would create a copy of the screen 
up in main memory, and WinVNC could read from this rather than from the 
graphics card.  In this case, the pixels would have to transit the bus 
twice instead of three times, but that's still once too many. 
Ultimately, the solution should have been to simply display the pixels 
into the window but have the interposer trigger the screen scraper 
(through some suitable IPC mechanism) to read back that window directly 
from the graphics card, i.e. eliminate the use of Pbuffers altogether. 
However, before we got too far into the development of the WinVNC 
solution, we switched gears and started using VirtualBox instead, and 
ultimately it proved to be a lot nicer.  The major commercial solutions 
for remote Windows 3D-- Microsoft RemoteFX and nVidia VGX-- ultimately 
settled on a virtual machine-based solution as well (although it should 
be pointed out that RemoteFX only accelerates DirectX, not OpenGL.)

Apart from the afore-mentioned bugginess of the TurboVNC Windows Server, 
an additional issue with the screen scraper solution was that the 
proof-of-concept interposer we developed was based on Microsoft Detours. 
  Detours is a proprietary library that would require a license to use 
commercially.  We would have needed to come up with a better way of 
doing the interposition of OpenGL calls that didn't require Detours.

There are other WinVNC solutions out there that are still active. 
TigerVNC, for instance, has the same basic codec as TurboVNC.  Their 
WinVNC implementation doesn't quite achieve the same levels of 
performance as TurboVNC, however, for reasons unknown.  TigerVNC's 
WinVNC will perform at about 2/3 of the performance of the TurboVNC 
Server, if memory serves.  The other issue is that TigerVNC's WinVNC 
doesn't work on Windows Vista and later.  In order to support Vista and 
later, it would have to be re-architected such that the VNC service and 
the configuration GUI are separate programs.  Our old TurboVNC version 
of WinVNC suffered from the same issue.  As with TightVNC 2.0, it would 
probably take a 100-hour effort to bring TigerVNC's version of WinVNC up 
to our standards.  There is no active development on WinVNC within the 
TigerVNC Project, since the primarily developers of that project use the 
same basic solution for remote Windows apps that we do (VirtualBox and 
VirtualGL.)

TightVNC 2.x does fully support Windows Vista and later and has a really 
nice interface, but it's very slow.  I can't put my finger on the 
benchmark results I conducted a couple of years ago, but memory serves 
that TightVNC 2.x was something like 1/10 of the performance of TurboVNC.

UltraVNC also fully supports Windows Vista and later and is much faster, 
but memory serves that it's still something like half the performance of 
TurboVNC, and I also recall encountering some pretty bad banding 
artifacts when attempting to play videos or run other high-speed image 
drawing workloads through it.

RealVNC Enterprise-- also really nice interface, but also not nearly as 
fast as TurboVNC, and not open source.  I seem to recall it being 1/3 or 
1/2 the performance of TurboVNC.

I should add that it's been years since I conducted the head-to-head 
WinVNC research, so any of the above statements may be out-of-date.  I 
will be re-running some of these tests in the coming weeks for a 
presentation.


In short, if you're just looking to remotely run Windows 2D apps, 
UltraVNC is probably your best bet on the open source side.  You can use 
the TurboVNC Viewer with it.  If you're looking to run Windows 3D apps 
remotely, use VirtualBox.  Since that's the solution we officially 
support, there isn't a lot of impetus for us to support our own WinVNC 
solution.  The lack of multi-user support in WinVNC makes it a 
non-starter for most serious remote 3D deployments, and remote 3D is 
what this project is all about.



On 8/14/13 2:15 PM, Arie Kruiniger wrote:
> To clarify, I want to use my windows machine as the VGL/Turbovnc server.
>
>   I've just noticed that the documentation for both
> (http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vgl/tags/2.3.2/doc/index.html,
> http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vnc/tags/1.2/doc/index.html#hd005004)
> only mention a windows client, not a windows server.
>
> Have I totally misunderstood and there's no windows server?
>
> Incidentally, I managed to install turbovnc and vgl successfully on ARM
> Debian.
>
>
> On 14 August 2013 18:44, Arie Kruiniger <akruini...@gmail.com
> <mailto:akruini...@gmail.com>> wrote:
>
>     Hey,
>
>
>     For Windows, I can only see vnc viewer as a download. How do I get
>     TurboVNC server?
>
>     Completely understand if this is something you have to pay for, just
>     curious

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Reply via email to