On 9/6/11 3:47 AM, Csillag Kristof wrote: >> However, the problem is that the compression parameters are very >> specific to the type of encoding being used. You couldn't, for >> instance, force a client to receive JPEG, because you have no idea >> whether the client even supports Tight encoding. > We can assure that all clients are using the latest version of turbovnc > / tightvnc client.
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.) This in and of itself would not be sufficient, because you'd also need a way to continuously stream updates to the client. (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. 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. 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. >> 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? 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? Note that, when using the default encoding settings in TigerVNC, images with less than 24 colors will always be lossless. > OK, so what is it that we _can_ guarantee? What is the XPutImage > synchronized to, then? > > We need to assure that every single frame the application draws reaches > the client. > We need to "slow down" the server to wait for everything to reach the > client. > The client must see every single frame, so that we can be sure that the > viewer does not miss anything that turns up on a frame, but disappears > on the next. > (It's a medical application, so it's imperative that this is strictly > enforced.) 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. >>> 3. We are going to transfer multi-megapixel images with a high >>> frame-rate. What do we need to do to enable multi-thread jpeg >>> compression with libjpeg-turbo? >> >> TurboVNC does multi-threaded compression. > Is this implemented in the libjepg-turbo codec, all hidden behind the > the standard libjpeg API? > Do we need to do something to configure/enable this, or is this on > automatically? No, it's specific to TurboVNC. It is documented in the User's Guide. >> However, multi-threaded decompression is not yet implemented-- >> basically, the company that was sponsoring the improvement backed out >> before I could finish it. > That's a pity. >> 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. >> We are still discussing how best to implement multithreading In TigerVNC. > So is there a need to support this on the tigervnc/turbovnc level, too? > Can not the jpeg codec handle this properly on it's own? No. There are two issues: (1) Not all rectangles are sent using JPEG encoding (2) The ones that are will never be more than 64 kpixels in size, meaning that there is too much overhead to multi-thread on that fine-grained a level. Instead, TurboVNC splits each update vertically among the available threads. Thus, if the update is full-screen, each thread gets a portion of the screen, and the entire Tight encoding process is parallelized, not just JPEG encoding. In order to further reduce overhead, the Tight encoding threads are maintained for the duration of the connection. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/tigervnc-users
