From: Adam T. <at...@re...> - 2008-04-14 09:24:31
|
On Fri, Apr 11, 2008 at 02:03:49PM -0500, DRC wrote: > > The reason why I suggested using JpegEncoder as the base for > > integrating > > TurboJPEG is because it's somewhat closer to the "TurboVNC way" ( as I > > understand it :) -- both use only JPEG and try to maximize update rate > > as much as possible. TightEncoder is different -- it prefers high > > compression to real-time transmission. > > Hmmm.... Yeah, that is potentially very interesting to us. But several > questions/concerns: > > 1) How would an application (VirtualGL) tell TightVNC to reserve an area of > the Xvnc virtual framebuffer for video transmission? The only way I can > think of is to create a new X extension. > > 2) Would VirtualGL have to track the position of its 3D windows and > continuously notify Xvnc of these changes? > > 3) Requiring VGL to "turn on" and "turn off" acceleration is potentially > problematic. If something were to go wrong and it failed to turn on or off > acceleration, then the user would never know it except for the fact that > their image transmission would suddenly become slower or they'd no longer be > able to switch off JPEG encoding. > I think this kind of optimizations are not needed in Xvnc. Every time when framebuffer is updated proper vncHook function is called and rectangle (or region) is added to queue as changed. When you mark some region that it should be always updated you have to execute all vncHooks stuff and in the end you find that region is already marked for update and you drop it. In the end you will have quite bigger CPU overhead, some heuristics in Xvnc (which will guess what regions should be updated automatically) and you will use more bandwidth. I didn't test what is faster but from my experience tracing changed regions and dumping framebuffer is really not performance critical section (of course in Xvnc, in x0vncserver situation is quite different) Adam -- Adam Tkac, Red Hat, Inc. |