I recently blogged on the new Thinwire Compatibiltiy Mode introduced in 7.6 FP3 and have had some great feedback.

It’s really satisfying to see customers care as much as I do about efficient bandwidth and CPU usage, there are lots of reasons you might want a low-cost graphics protocol:

  • Battery life on mobile devices – both CPU and GPU usage drain batteries;
  • Get more users on your existing hardware;
  • Avoid costly network upgrades;
  • Improve user experience by allowing high frame rates;
  • Avoid paying for bandwidth on WiFi, 3G/4G.

Sometimes, Less is More!

While many applications have become graphically rich in recent years, lots more haven’t:

  • Applications designed for mobile devices have got flatter and simpler, lots of primary colour blocks, in recognition they’ll often be used with tiny screens and on limited bandwidth;
  • Applications your average office worker uses heavily aren’t graphically demanding – think about Microsoft Word, where a user is usually typing black text on a white background;
  • Bespoke legacy applications are in fact very simple with interfaces similar to a DOS/unix shell, say.

Even if an application is graphically rich, sometimes you might not want all that rich graphical information (or to pay for the bandwidth to transmit it).

Thinwire Compatibility 16-bit Mode

Thinwire Compatibility Mode implements an optional 16-bit graphics mode for reducing bandwidth usage. Tests here at Citrix indicate a ~15-20% bandwidth reduction for typical “Office”-type workloads. Unlike Legacy Mode, enabling 16-bit does not affect application compatibility and can be configured by setting the “Preferred Color Depth” (user) policy to “16-bit”. The quality degradation is barely perceptible.

Lower Still – Experimental 8-bit Mode!

(Disclaimer: this is an experimental feature and is not supported by Citrix, it is provided for evaluation to solicit feedback on potential new features and should only ever be used in a test environment and never in production environments.)

I’ve added an experimental 8-bit setting for ultra-low bandwidth usage. To enable this, add the following registry value on the VDA on which you wish to use 8-bit:

[REG_DWORD]      HKLM\Software\Citrix\Graphics\LowBandwidthMode

  • Set this registry value to “2” to force an 8-bit session.
  • Set this registry value to “1” to force 16-bit, although this should be done using the “Preferred Color Depth” policy.

Once set, all connections to that VDA will show in 8-bit colour. At the moment we have only tested this with Linux and Windows end-points – feedback on other devices would be welcomed!

As with 16-bit mode, application compatibility isn’t affected. However photographic imagery will obviously appear degraded somewhat – 8-bit is really intended for simple workloads (e.g., Office/web-apps/etc.), where it provides a perfectly acceptable experience especially if bandwidth is a major consideration. We’ve seen up to 50% (!) reduced bandwidth as compared with Thinwire Compatibility mode’s default out-of-the-box settings.

What to expect

First, here’s a screen grab of a 24-bit session configured to use Thinwire Compatibility in it’s default mode.

24

As you can see, the Windows 10 wallpaper and photographic imagery within the browser are of high quality and you’d be hard-pressed to tell the difference between a local and remote session.

Now, with the 16-bit policy enabled:

16

Photographic imagery within the browser looks very similar to the original 24-bit image, however, some gradients become apparent in the Windows 10 wallpaper. Still, perfectly acceptable.

And finally, 8-bit:

8

All photographic imagery degraded, however, it is still possible to pick out detail and more importantly, text & solid colour areas are largely preserved.

Please have a play and let me know what you think!

More Disclaimers

Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

The above post covers a product configuration or procedure which Citrix does not currently offer support for.  Use of this configuration should only be used in a lab or test environment and not with production deployments.  The author is actively seeking feedback on the potential of implementing support for this configuration, but the form any level of support takes has yet to be determined.