On 8/23/13 6:09 PM, Göran Krampe wrote: >> was a non-starter as a remote 3D solution for technical computing, but I >> also looked at the general performance, and I wasn't able to push more >> than about 1/3 the pixels that TurboVNC is capable of. I agree, though, >> that it does bear further investigation. > > And you had RemoteFX enabled with a GPU on the server side? Just so that > you didn't just use "plain RDP" ;)
Everything was enabled, but I'm not sure when it uses the plain RDP protocol and when it switches to RFX. I guess I probably assumed that it was using RFX all the time when RemoteFX was enabled, but that may have been a fallacious assumption. It might be necessary to actually run something with 3D acceleration (i.e. a DirectX app) in order to get it to use the enhanced codec. > Thanks for the details! It is quite interesting all this, and I also > find it "odd" that TurboVNC isn't more "known" in general (although > professionals in visualization clearly knows). You hold a fairly low > profile :) Not by choice. As an independent developer, I don't have any marketing resources, nor any time to pursue anything other than development. I rely on word of mouth through the open source community. We have gotten some good press through my work with Santos, though, whose project replacing all of their workstations with laptops and VGL/TVNC earned them the Red Hat Innovator of the Year Award in 2011. TurboVNC has always been viz-focused, and it is only recently that I've done the research to show that it is capable of more general-purpose use as well, and this was facilitated by retrofitting TigerVNC's codec to work like TurboVNC in 2011 and porting the TurboVNC codec into libvncserver this year. Both of those are more general-purpose VNC solutions and served as a much-needed acid test for our approach. I do still feel like a lot of people don't know about TurboVNC, though, and what most concerns me is that there are a lot of people who are still using TightVNC 1.3.x, either as end users or writing products around that codec. TurboVNC is the most logical upgrade path for TightVNC 1.3.x, since we were originally based on it. > So yes, I agree - I only need to "wrap" my Linux apps with vglrun so > that I get the OpenGL rendered and pushed through as jpeg. When you are running VirtualGL in an X proxy, VirtualGL doesn't do the compression. It simply draws X images and lets the X proxy handle the actual compression. > Also I just realized there is no audio in TurboVNC, funny enough I > thought there was because I "heard it" but I was of course running > everything locally so I was "hearing the server". Any views on sound > output/input? > > I noted the QEMU extension, but agree that it might be "stupid" to mix > audio into the same TCP socket. Seems people use PulseAudio "on the > side" for this, do you (or anyone) know more about that? ThinLinc apparently provides audio, and since they're built upon TigerVNC (which doesn't provide audio), I'm assuming they use a separate mechanism for it. I'm not aware of any way to transmit audio through RFB, so I am imagining that a separate connection for audio is necessary. I really don't know much about it, though. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
