Citrix has long talked up “SpeedScreen Latency Reduction” (or “SLR” for short) as a benefit of MetaFrame Presentation Server, but I’ve found that most people don’t actually know exactly what it does or how it works. I’d like to go on record by saying that it does work, I think it’s awesome, and it’s a great feature of Citrix MetaFrame Presentation Server that doesn’t exist in any other server-based computing product.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
If you use Citrix MetaFrame in environments with more than about 150ms of latency between the ICA client and the server, then this article is for you!
What is SpeedScreen Latency Reduction?
Quite simply, SLR is technology built into MetaFrame Presentation Servers and ICA clients that allows users to experience smooth typing in environments where there is high latency between the ICA client and the server. Using SLR properly can, for example, allow a user to have a smooth typing experience while writing a Microsoft Word document—even if there is 200, 500, or (gasp!) 1000ms of latency between the server and their ICA client.
Citrix’s SpeedScreen Latency Reduction does two things. Firstly, (and most importantly), it provides something called “local text echo.” Local text echo allows characters to appear on the ICA client device’s screen the instant a user pushes the key on their keyboard.
For example, imagine a situation without SLR where a user is typing a document via an ICA session with 400ms of latency. When the user presses a key, the ICA client sends that key press code to the server. The server receives it, processes it, puts the character into the screen buffer, and sends the new screen image to the client device. However, due to the 400ms latency, the actual character doesn’t show up on the user’s screen until about a half-second after they first pushed the button. To the user, it would appear that there is a half-second “lag” when typing.
To address this, SLR’s Local Text Echo causes the ICA client to behave a bit differently. When enabled, a user pressing a key on their keyboard causes that key code to be sent to the server. However, at the same instant, the local ICA client software also draws the appropriate character on the user’s screen even though the actual screen drawing instructions from the server are bogged down in the 400ms latency between the client and server. Then, once the ICA client finally receives the actual updated screen from the server, it doesn’t have to update that character on the local screen since it already put it there back when the user pressed the key.
In a sense, SLR’s Local Text Echo is kind of like a “pre-caching” of the text. Local Text Echo is totally awesome and works really well. It works with all different fonts and font sizes.
The other major SLR feature is something called “Mouse Click Feedback.” This addresses another common problem in Citrix environments with high latency, namely, the fact that users click on a button, become impatient, and click on a button again before the first click registered. Then, when the application’s response finally makes its way to the user, whatever the user clicked on comes up twice.
Mouse Click Feedback works by adding the hourglass symbol to the arrow cursor the instant the user clicks the mouse anywhere within the boundaries of the remote ICA application. It does not technically prevent the user from clicking the button twice, but the general idea is that the user will see the hourglass and then have the patience to not click the button again.
In most environments with latency, people use both the Local Text Echo and Mouse Click Feedback components of Citrix’s SpeedScreen Latency Reduction.
How does SpeedScreen Latency Reduction work?
The two different components of SLR are independent of each other and work in different ways.
The instant mouse click feedback is quite simply an ICA client-side configuration. It doesn’t really matter how the server is configured. When instant mouse click feedback is enabled, the local ICA client simply switches the local cursor to the one with the hourglass attached to the arrow whenever the user clicks a button.
Local text echo is a bit more complicated, (Okay, it’s a lot more complicated.) In order for local text echo to work, the ICA client needs to have whatever font is being used in the server session installed locally on the client. (After all, how could the client generate the appropriate characters on the screen if it didn’t have the proper font?) To do this, the client and server compare their lists of installed fonts whenever an ICA session is started. Any differences are noted. (It’s important to point out that the server and the client do not synchronize, transfer, install, or copy any fonts. They merely create a list of fonts that are installed on both sides.)
Then, when an application is launched on the server, the server looks at the various text fields that are visible in the current application window on the screen. Specifically, it’s looking for windows fields that are of a type called “Edit” or “RichEdit.” An “Edit” field is pretty much any text box or text field where text can be typed that cannot be styled (i.e. username and password fields, HTML form tags, notepad, the calculator display, etc.). A “RichEdit” text field is a text field that can contain styled text (WordPad, Microsoft Word, etc.).
Whenever an ICA user types text within an Edit or RichEdit field from within a session that has SpeedScreen’s local text echo-enabled, the client simply renders the fonts directly in the window the instant the user pushes the buttons. When enabled, SLR utilizes one of the ICA protocol’s virtual channels to pass SLR data back and forth between the client and the server.
Local text echo only works for typing a stream of characters. You can change fonts, font sizes, and add new lines, but complex things such as highlighting and deleting large chunks of text exhibit the lag associated with the actual latency.
SpeedScreen is automatically used on a MetaFrame server whenever a user connects to a session that has between 150 and 500ms of latency. As long as the client supports it, it's used.