2011/9/6, DRC <dcomman...@users.sourceforge.net>: > The way I see it, there are basically two approaches you could take: > > (1) Some form of a "force encoding" function, which would have to be > implemented as an X11 extension (possibly extending the existing VNC > extension in TigerVNC.) We have done something similar with NX earlier, but we did not use an X11 extension; we have specified a few special values, which (when passed to the X server in regular X Atom setting calls) triggered the desired behavior. The advantage of this approach was that we did not need to define a new X extension, and that the application could be used on normal X server, too. (Then the same X calls don't do anything.)
We can talk about this later. > This in and of itself would not be sufficient, > because you'd also need a way to continuously stream updates to the client. You mean the configuration updates, right? How could we implement this? (Maybe introducing a new extension of the RFB protocol?) >> (2) Some sort of a "compressed PutImage" function which basically allows > you to pre-encode the image (using libvncserver, for instance) and then > inject it directly into the output stream of VNC. That might work, too, but this would involve heavy modification of the X application, which is not desirable. We would prefer the first approach, because this is similar to what we have done with NX earlier, so we can implement this in a compatible manner, without changing the application layer. > Solution #2 might be of interest to me, as the author of VirtualGL, but > in either case, the solution is messy, because it allows the application > to easily crash the client if the client doesn't support the type of > encoding that is being sent. In our case, we are controlling both the client and the server, so this is not a problem. > I don't see either as being broadly > beneficial, which means that getting people interested in developing, > testing, and maintaining the feature will be difficult. If we decide to take this approach, then we will develop, test and maintain this feature. >>> Perhaps if you explain more about why you want to do this, we can >>> propose a cleaner solution. >> We are required to configure the compression level according to some >> central policies, dictated by other requirements. >> There are situations when we absolutely need to do lossless encoding >> (whatever the performance is), and in other cases, >> we would like to configure the lossy compression level according to some >> external bandwidth usage policies. >> >> This all must be handled on the server side, in a centralized manner. >> (And run-time changes are required, too, because the type of content to >> transfer might change; some needs lossless quality, and some can do with >> lossy, so we must be able to change it, from the application side.) > > Are you using VirtualGL or is this a 2D application? Simple 2D. (Contains some 3D content, too, but that's rendered in software, too.) > From the X server's point of view, is there anything that distinguishes the > type of > content that must be sent as lossy vs. lossless? No, the same content must be sent over in different compression in different situations. The user is usually watching in in lossless, but sometimes he says "stop, go back, let's replay this with lossless compression". It must be possible to configure this with the built-in controls of the application, so that the workflow is properly integrated. (Configure lossless compression, rewind the data with one step.) > It's a pipeline. Thus, before each XPutImage() call will return, it is > guaranteed that the *previous* XPutImage() call will have been sent, and > the client will receive all of the XPutImage() calls as long as the > client is connected. However, it cannot be guaranteed that the > *current* XPutImage() call will be received by the client before > XPutImage() returns. Doing such would require an acknowledgement from > the client, which would kill performance. I see. So, generally, this _will_ force the server-side to use an FPS that the client can process; but the client will be 1 frame behind. Do I understand in properly? If yes, than this might be acceptable? How can we try this configuration? * * * One more question: if we tried to remove this one-frame delay, and would prefer to actually wait for the acknowledgement, then a) how much work would it be to implement this, and b) how much do you expect it to "kill" the performance? (Let's assume we are working with 5-10ms network delays.) > No, it's specific to TurboVNC. It is documented in the User's Guide. I see. >>> Multi-threading the compressor is of only limited usefulness without >>> multi-threading the decompressor as well. >> Sure, but still, the server side tends to have more cores than the >> client side, so it's still a gain.. > > Not necessarily, because the client is often still the bottleneck. True. We have just seen a similar bottleneck with NX and TurboJPEG/IPP; a 4 megapixel session capped at 10 FPS, because of client CPU saturation. (saturating 1 core of the 8 available ones, btw.) We will do the same measurement with TurboVNC, as soon as we can get the CU feature to work. What kind for performance do you think the current version of TurboVNC is capable of if - the server is strong enough - there is an 1Gb network connection - the session is 4MB - Jpeg compression is enabled - the client is reasonably fast (but not super-fast) ? * * * How much time (and money) do you think it would take you to finish the multi-threaded decoding on the client side? (I am just inquiring, I am in no position to decide anything like that, but I can propose this to my managers, if that's feasible.) * * * Than you for your help: Kristof ------------------------------------------------------------------------------ Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
