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