On 5/26/11 1:10 AM, Arthur Huillet wrote: > Indeed my code is not going to do a refresh in this case, as the image is > not idle. My position is that if an application behaves incorrectly it > should be fixed, and a terminal with a blinking cursor is not an > interesting use case for ALR anyway (if you're running just a terminal, > increase > the JPEG quality or don't use JPEG). > > (About "should be fixed": this is very serious, not just because of VNC > but because of power management issues.)
There are many 3D applications that have a terminal with a blinking cursor integrated into them. If I just threw up my hands and said "the application needs to be fixed" every time I encountered an issue like this, VirtualGL would still just be a science fair project. A good portion of my work in the past 7 years has been spent working around aberrant application behavior-- moreso with VirtualGL than TurboVNC, but TurboVNC is certainly not immune from this. After 7 years of existence as an open source project, I feel like we finally have enough traction to where we can reasonably expect application vendors to work with us, rather than us working around them, but that level of engagement takes time. The specific issues with ill-behaved taskbars are with several different O/S distributions which shall remain nameless. It isn't as simple as just saying "you can't use ALR with that distro." >> I'm being paid to come up with an automatic lossless refresh solution >> for TigerVNC, so I'll be revisiting some of these assumptions over the >> next few months. At the moment, my inclination is to leave TurboVNC as-is. > > I'm looking forward to that. In the meantime I will give more testing to my > patches, evaluate whether they are fit to my use cases, and distribute them if > so. I would say that the odds of them being incorporated into TurboVNC are slim. I need to open a dialog with the TigerVNC developers as to the best way to implement ALR in that code base. I really don't like the idea of implementing it on the server, because it requires a separate thread (I expect push-back from TigerVNC on that as well.) However, I don't know of any other way of being able to enable ALR for only a specific type of X request. At the end of the day, the implementation of ALR in TurboVNC is stable, and people are successfully using it, so I don't want to replace it unless there's something much more compelling to replace it with. At the end of the day, the client-driven nature of the RFB protocol is pretty nasty, and the reasons why it is client-driven are no longer valid. Setting up a separate compress/send thread on the server for each connected client and setting up a true back buffer for the client display would eliminate the need for the client to send framebuffer update requests. A proof of concept for this is implemented in the TurboVNC CVS Head (the "Continuous Updates" feature.) However, it is still a bit science-fair. It has to make some simplifying assumptions, such as only making certain types of requests eligible for CU (currently, PutImage or XCopyArea requests of >= 65 kpixels.) It's a bit of a hack to attempt to improve the performance of TurboVNC on high-latency networks when using VirtualGL, but there are still some fundamental architectural aspects of VNC that need to change. How to make those changes without breaking compatibility with other VNC implementations is the challenge. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
