Understanding Citrix's SpeedScreen Latency Reduction

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.

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.

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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by an anonymous visitor on September 7, 2004
Hi Brian, I've noticed that SLR is normally set to automatic and will NOT kick in unless the high SLR server threshold is met (500ms by default). Is that what you have noticed as well? Also, when I have used local text echo, the characters are inserted into the doc (while waiting for the server's latent response) but not using the same appearance of regular text -- instead the text is superscript, subscript, larger or smaller in size, and sometimes in a different color until the server sends back the update to the screen. Soon as when the packets are received by the server and sent back to the client, the correct size, color, and shape now appear in the document. Is this not your experience with it as well?
This message was originally posted by Ron Oglesby on September 9, 2004
For the font changes it depends on a few things. Basically when SLR first "kicks-in" the serverside SLR componenets try to detect the font, size and color being used in the applications. Some apps it does this very well (depending on the type of input field and how the app was written). Anyway the idea is that based on this poll of the app it sends a glyph map/set of images representing letters and numbers. So what you see on the client is based on that picture map and that map is based on what is sent from the server, which in turn is determined by the polling and the app. Some apps just dont detect well and at all and you need to determine a set font and color or size to use, or change the type of detection on the app through the SLR configuration. Of course this may increase server utilization some but can fix the issues. Anyway I like to look at each application and adjust them as needed.
This message was originally posted by an anonymous visitor on September 14, 2004
Don't you still need to add this to template.ica to have it enable via WI?
This message was originally posted by an anonymous visitor on October 14, 2004
Excellent and well written article. I learned more from this than from searching the Citrix web site in both the Knowledge base and the user forum.
This message was originally posted by Christoph Schmitz on November 11, 2004
When surfing web pages that require a login, SLR and LTE will sometimes cause inputs into password fields to be displayed in clear text. The input is masked with asterisks (as should be) after a short delay. So anybody looking over your shoulder can see your pwd in clear text.

This only happens with web pages in frames and iframes though. It seems the framesets cause a delay that is big enough for LTE to display the clear text when typing.

I found two solutions:
- disable SLR or at least Local text echo
- don't use frames

You'll notice the difficulty in a situation where you have a big number of users and a big intranet site that relies on frames...




We had a problem with speedscreen using the web client to access Cognos PowerplayClient.. When using the "+" sign to expand menu at a certain level the IE6 seems to hangs and stop to display anything. This happend accross opur Wan but NOT on the lan... So it was pretty obvious that the threshold to to seppedscreen has been reach and be set "on" ... Disabling SpeedScreen resolves the issue
Remember also that instead of disabling speedscreen altogether you can create a profile for that application and just disable speedscreen for that application. Or, you can tune it even further and just disable it for certain parts of that application.
Thanks Brian... We were in the process to do So... Also we have find that a HotFix has been published by citrix for version 3
... Do know if it will fix our problem since we are using this version Yet...

Again Thanks for the Feedback

And congrats for the So useful WebSite

Best regards

We have a PS4.0 environment using Web Interface and CSG 3.0. PS 4.0 and Web Interface are on the same box and the CSG is on another one. We've enabled SLR on the server. When using web interface, we connect using the low bandwidth option in the connection settings.

Now, we can tell it works from some clients as we see the fonts being re-adjusted as we type. Text will also overlap the fields if we type fast enough. This is what we expect from the local text echo. Also, under Connection Center, the application has both SpeedScreen and SpeedScreen Latency Reduction showing as ON. The client we use is version 9.0.

The problem we have is that, for some clients, although the Connection Center shows the application has both SpeedScreen and SpeedScreen Latency Reduction showing as ON, we don't "feel" the local text echo. Fonts are not re-adjusted and text won't overlap. We've experienced this with a Citrix client installed on a Windows 2000 server, on some laptops running Windows XP but can't find a pattern here...The same ICA client is installed on all the clients we are testing, we open the connection always the same way from Web Interface, pointing to the same Citrix server.

Could this be related to a video driver problem or fonts not matching between the client and the server? What would be the easiest way to debug this?


I'm packaging the ICA Client and want to know where the settings for SpeedScreen are stored.  Are they in the registry or an in file?

I have a problem on launching an application when i turn on the SLR in the WI (default.ica) and enable local text echo on the citrix server. I have CSG 3.0 (WI 4.2) and PS4 running on windows 2003 sp1. I cannot verify if SLR is working or not. Please help me.
I just encounter the same problem, but i resolve it by checking the DEP setting of ur Windows 2003 server with sp1, then apply this patch from citrix to fix some problems http://support.citrix.com/article/CTX109307&searchID=32214123, to know more about DEP go to this site : http://support.microsoft.com/kb/875352. Hope this help to solve your problem. :)
To verify that ur SLR is configured, after the application is launch, press shift + F2 for full screen, if u successfully configure the SLR, u will see a (SpeedScreen : on) on the application.


I connect through Citrix using an URl portal login to connect to an ASP - How do I know if SLR is enabled? If so would it be enabled on my local machine by default or at the server side?

Your advice appreciated 


Hi guys,

I'm new to Citrix and all it can do.

Thanks for this article. I have a question that maybe someone here can answer... 

Citrix claims to improve PACS (Picture Archiving and Communication Systems) images, which are medical images. If SpeedStream is only used for mouse and keyboard enhancements, how can Citrix claim a 97% improvment in PACS transmissions?

Is there something else like image caching or other that SpeedStream does which isn't discussed in this article?

If it's not necessary to go the Netscaler or Wanscaler route, I'd like to look into already available technologies if you know what I mean. :) 


How can I implement speed screen to improve PACS performance via citrix or even VNC performance via Citrix?

You can disable SLR based on the application.  We have the same problem with IE displaying passwords.  You can configure the server to disable SLR on iexplore.exe only.

SLR is very easy to replicate across your entire farm too - there si no need to configure each server individually; I came across this guide which details how to do this:<a href="cb-net.co.uk/index.php target="_blank">http://cb-net.co.uk</a>   


citrix is something new and very intersting


We have an application hosted in the USA that our Europe users access.  They get the Hour Glass pointer, but once they get the Hour Glass, it never goes away.  How do fix that?