H.264 Build to Lossless
The “Build to Lossless” visual quality policy setting has been around for as long as I’ve been working on HDX, and believe me, that’s quite a long time! Enabling this policy puts Thinwire — our graphics remoting technology — into a mode we think is optimized for 3D-type workloads that need a final pixel-perfect image, for example, manipulating medical imagery.
The idea behind build to lossless is simple: give the best interactivity during user input and sharpen to lossless once activity ceases. Image quality is reduced — in accordance with available resources —during the interactive phase in order to maintain the best possible frame rate. Moreover, we sharpen up in an “interruptible” manner (i.e., part by part) so that the session remains interactive in case the user decides to move off again.
What’s new?
Historically, we’ve used variable quality JPEG which does a decent job in most scenarios, but suffers quite badly when bandwidth is limited or latency is high. With 7.18 comes an exciting new enhancement to build to lossless: H.264 is now supported! Providing you’re using a Windows or Linux Receiver, H.264 is used instead of JPEG in the interactive phase and the same “interruptible” sharpening scheme is used to build to lossless. Furthermore, the way in which the H.264 quality is adapted has also changed with the end result being much better interactivity, especially in WAN scenarios (e.g., 1-20 Mbps, 40-250 ms). Take a look for yourself:
No new policies or Receiver upgrades are needed to take advantage of this enhancement. Simply make sure the “Use Video Codec” policy is set to “Use when preferred” (default) or “For actively changing regions”. If you’d like to revert back to using JPEG for build to lossless, set the policy to “Do not use”.
Progressive Display
Screen response time can really suffer on low bandwidth or high latency connections. We’ve all been there before: scrolling through a web-page — or rather, crawling — waiting for images to load or text to show. With HDX, or indeed any remoting protocol, there’s the added frustration of the screen not updating quick enough in response to user input, for example, scrolling with the mouse-wheel.
Up to and including 7.17, it is possible to help interactivity by configuring the session to “Low” visual quality, or setting a lower colour depth (16 or 8-bit graphics). Both reduce bandwidth consumption and both can be set by policy. The problem with doing this is that the administrator must have prior knowledge that a user is on a weak connection: there is currently no way in which Thinwire will dynamically adjust quality based on network conditions.
What’s new?
Progressive display attempts to alleviate some of this frustration by sensing poor network conditions and taking corrective action by reducing image and text quality during user activity. Once things settle down, the image and text quality is gradually built to lossless. This uses slightly more bandwidth in the long run but interactivity (response time) is greatly improved when it matters.
Progressive display is in “standby mode” by default, and just like H.264 Build to Lossless, needs no Receiver upgrades or new policy settings to make it work.
More information on both of these cool new enhancements can be found in the 7.18 XenApp and XenDesktop documentation. As always, I’m eager to know what you think. 🙂
