Show window contents while dragging

Let’s test your XenApp/XenDesktop design skills.

With XenApp/XenDesktop 7.15, do you want to show window contents while dragging?

NO CHEATING! Answer before continuing

First, we need to understand that the “Show window contents while dragging” is an operating system setting and not a unique XenApp and XenDesktop setting. But this setting does impact the performance of XenApp and XenDesktop. The question is how?

To answer this question, we have to look at Thinwire, which is one of the many display codecs within the ICA protocol. Thinwire excels at identifying movement. If I have an application window at position 50,50 and then move it to position 51,50 Thinwire understands that it isn’t an entirely new object, but that a previous object (application window) moved from one location to another.

By understanding that a window moved positions, Thinwire sends a small move command to the endpoint instead of sending new pixels for each item within the application window.

But what happens if we disable showing window contents while dragging?

As soon as the user selects the application window to initiate a drag, the entire application windows gets replaced with 4 lines, a few pixels wide, equal to the application window’s dimensions. The four lines are not equal. The four lines are not static from one move to the next. The operating system changes the size and pixel width based on whatever is behind the lines. Due to this dynamic nature, these lines are not friendly to the Thinwire cache, which means Thinwire must draw fresh lines each time the user drags a window. And because the application window’s contents are replaced, we need more bandwidth usage, which could result in a poorer user experience over constrained links.

A big thanks to Muhammad Dawood and Nick Rintalan for answering this question for me.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.15 VDI Handbook
XenApp Best Practices
XenApp Video


4 thoughts on “Show window contents while dragging”

  1. Hi Dan,
    Interesting find indeed, but… I think that this is one of those cases of “real world” vs. “lab world”, so yes it might be true that if you take a window and in one swift move pick it up at position 50,50 and drop it at exactly position 50,51, in that case, you have less bandwidth used and almost no CPU, nice, quick, and easy. In the real world users are not picking up and dropping anywhere near as efficiently as that, they are moving windows around while they decide where to put them, in most cases holding the window hostage, driving up CPU and bandwidth. I can’t say for sure, but my understanding is if you pick up a window and move it all over the place, never letting it go *and* you have window contents on, then, in this case, Citrix has no choice but to keep track of the window and all of its contents and constantly redraw them, just in case that spot happens to be the lucky one where you actually decide to let it go, not to mention the CPU will be through the roof and affect overall performance of the session.

    In these real-world scenarios, I wonder what the bandwidth becomes vs the 4 lines that definitely need to be drawn. In my experience, the latter is better overall, at least on user perception.

    Now what might be interesting and sway me is if you throw a GPU into the mix, then you relieve the system of having to do anything in the CPU as well as the potential bandwidth savings, that might be a real winning combination!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s