Thinwire is the Citrix default display remoting technology used in XenApp and XenDesktop.
Display remoting technology allows graphics generated on one machine to be transmitted, typically across a network, to another machine for display.
A successful display remoting solution should provide a highly interactive user experience that is similar to that of a local PC. Thinwire achieves this by using a range of complex and efficient image analysis and compression techniques. Thinwire maximizes server scalability and consumes less bandwidth than other display remoting technologies.
Because of this balance, Thinwire meets most general business use cases and is used as the default display remoting technology in XenApp and XenDesktop.
Thinwire should be used for delivering typical desktop workloads, for example, desktops, office productivity or browser-based applications. Thinwire is also recommended for multi-monitor, high resolution or high DPI scenarios, and for workloads with a mixture of video and non-video content.
Framehawk should be used for mobile workers on broadband wireless connections where packet loss can be intermittently high.
In its default configuration, Thinwire can deliver 3D or highly interactive graphics. However, we recommend enabling HDX 3D Pro mode using the Citrix policy Optimize for 3D graphics workload for such scenarios when GPUs are present. The 3D Pro mode uses the GPU for hardware acceleration and configures Thinwire using optimal settings for graphics. This provides a more fluid experience for 3D professional graphics. For more information, see HDX 3D Pro and GPU acceleration for Windows Desktop OS.
Note: We do not support legacy graphics mode in this release. It is included for backward compatibility when using XenApp 7.15 LTSR, XenDesktop 7.15 LTSR, and previous VDA releases with Windows 7 and Windows 2008 R2.
Thinwire is the default display remoting technology.
The following Graphics policy setting sets the default and provides alternatives for different use cases:
A number of other policy settings, including the following Visual display policy settings can be used to fine tune the performance of display remoting technology and are all supported by Thinwire:
To get the Citrix recommended combinations of policy settings for different business use cases, use the built in Citrix Policy templates. The High Server Scalability and Very High Definition User Experience templates both use Thinwire with the optimum combinations of policy settings for your organization's priorities and your users' expectations.
You can monitor the use and performance of Thinwire from Citrix Director. The HDX virtual channel details view contains useful information for troubleshooting and monitoring Thinwire in any session. To view Thinwire-related metrics:
1. In Director, search for a user, machine or endpoint, open an active session and click Details. Or, you can select Filters > Sessions > All Sessions, open an active session and click Details.
2. Scroll down to the HDX panel.
3. Select Graphics - Thinwire.
In XenApp and XenDesktop 7.16 and earlier, there are three Thinwire bitmap encoding modes used for server OS and desktop OS VDA graphics remoting:
Legacy GDI remoting uses the XPDM remoting driver and not a Thinwire bitmap encoder.
In a typical desktop session, most of the imagery is simple graphics or text regions. When any of the three bitmap encoding modes listed are used, Thinwire selects these areas for lossless encoding using the 2DRLE codec. At the Citrix Receiver client side, these elements are decoded using the Citrix Receiver-side 2DRLE decoder for session display.
Lossless compression codec (MDRLE)
In XenApp and XenDesktop 7.17, we've added a higher compression ratio MDRLE encoder that consumes less bandwidth in typical desktop sessions than the 2DRLE codec.
Lower bandwidth usually means improved session interactivity (especially on shared or constrained links) and reduced costs. For example, the expected bandwidth consumption when using the MDRLE codec is approximately 10–15% less compared with XenApp and XenDesktop 7.15 LTSR for typical Office-like workloads.
Configuration isn't required for the MDRLE codec. If Citrix Receiver supports MDRLE decoding, the VDA uses the VDA MDRLE encoding and the Citrix Receiver MDRLE decoding. If Citrix Receiver doesn't support MDRLE decoding, the VDA automatically falls back to 2DRLE encoding.
Session interactivity can degrade on low bandwidth or high latency links. For example, on a link with bandwidth < 2 Mbps or latency > 200 ms, scrolling on a web page can become slow, unresponsive, or bursty. Keyboard and mouse operations can lag behind graphics updates.
Through version 7.17, you might use policy settings to reduce bandwidth consumption by configuring the session to Low visual quality, or set a lower color depth (16 or 8-bit graphics). However, you needed to know that a user was on a weak connection. HDX Thinwire could not dynamically adjust static imagery quality, based on network conditions.
In 7.18, by default, HDX Thinwire switches to a progressive update mode when available bandwidth falls below 2 Mbps, or network latency exceeds 200ms. In this mode:
Transient imagery (video) is still managed with adaptive display or Selective H.264.
By default, progressive mode is on standby for the Visual Quality policy settings: High, Medium (default), and Low.
Progressive mode is forced off (not used) when:
When progressive mode is on standby, by default it is enabled when either of the following conditions occurs:
After a mode switch occurs, a minimum of 10s is spent in that mode, even if the adverse network conditions are momentary.
You can change the progressive mode state with the following registry key:
0 = Always off (do not use in any circumstances)
1 = Automatic (toggle based on network conditions; this is the default)
2 = Always on
When in automatic mode (1), you can use the following registry key to change the thresholds at which progressive mode is toggled:
Value: <threshold in Kbps> (default = 2048)
Example: 4096 = toggle progressive mode on if bandwidth falls below 4 Mbps
Value: <threshold in ms> (default = 200)
Example: 100 = toggle progressive mode on if network latency drops below 100ms.