On 4/24/13 9:16 PM, Yusen Li wrote: > encoding is excellent for video games and the Turbor VNC or TigerVNC is > not good at games. I also suggested TigerVNC group to add the video > encoding techniques (such as x264) to TigerVNC. But they told me they > don't want to do that since the encoding is just good for a special set > of applications (games and video).
I was the one who answered that question on the TigerVNC tracker (https://sourceforge.net/tracker/?func=detail&aid=3611531&group_id=254363&atid=1126849). I didn't say "I don't want to do that." What I said was that H.264 encoding is not a panacea, and in order to realize the performance benefits of that technology, we would likely have to restructure the way in which VNC sends images. Basically, instead of sending incremental framebuffer updates for just the changed regions, we'd have to treat the whole desktop like a video stream and send the whole thing any time even 1 pixel changed, thus allowing the H.264 encoder to take care of interframe optimization. As you can imagine, that is almost certain to introduce severe performance degradation with any app that isn't a full-screen video app or game, and thus it would have to be a very specialized mode that isn't enabled by default. I am not sure whether there is an H.264 RFB encoding assigned yet, but if not, then we'd have to go through the process of getting it approved and defining how the encoding should work. It would be a lot of work to implement it, and I am not convinced yet that we can't come up with similar performance to H.264 by tweaking the settings in TurboVNC or TigerVNC. Minimally, however, if H.264 does prove beneficial for certain types of apps, it's not going to be a general-purpose solution, and thus it will be hard to secure funding for that research, particularly considering that it is speculative. I'm certainly always willing to take on challenging projects, but not for free. H.264 support would be a much better fit for the VGL Transport, since it is tied closely to the concept of 3D frames and will only send 3D pixels to the client. Of course, the problem there is that H.264's primary purpose is to reduce bandwidth, and thus it's really not very useful on LANs, but since the VGL Transport relies upon X11 to send the non-3D elements of the application GUI, it isn't really useful on WANs. Perhaps if you explain what you mean by "TurboVNC is not good at games"? Many people are using it for precisely that. The default settings in TurboVNC are not appropriate for WAN use, so if you are having performance issues on a low-bandwidth link, you probably need to dial down the image quality. Game workloads (specifically Quake 3) are one of the things I tested when designing the TurboVNC encoding methods. Those types of workloads are not significantly different, from TurboVNC's point of view, than Google Earth. In both cases, most of the screen is updated on each frame, and typically the updates are mostly encoded as JPEG, so changing the image quality will have a big effect on overall bandwidth. Anyhow, I'm not trying to convince you to use TurboVNC instead of xpra. I'm just saying that xpra isn't a technology we directly support, other than to make sure that VirtualGL works properly with it. I wasn't able to get xpra up and running, so I have no way of confirming for myself whether VirtualGL works with it or not, but other users are reporting that VGL works fine with it, so this does seem to indicate that this is either an xpra issue or an issue with your specific configuration. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
