Transparency, taskbar, and high CPU usage
Lately I have been using flexVDIClient full time, and I have noticed that the fan in my PC turned into high speed frequently, due to CPU usage. So I investigated the issue, expecting I could find a way to optimize the program. What I found was quite unexpected, though.
First I will describe my setup: my computer is a Windows 7 laptop with a 1366×768 screen, and an additional 1920×1080 monitor in the right side. GPU is an Intel HD Graphics 4000, and the processor is an Intel i5.
My favorite layout is using the full big screen in the right side for a flexVDIClient connected to the console of one of my VM´s, and the small one for messaging, email… The windows taskbar is in the bottom of the left screen, where I can see the notifications.
My desktop looks like this:
First Observations:
Initially I found that when flexVDIClient was full screen, the global cpu usage (4 cpu threads) was around 45%, with “System“ as the main CPU consumer. As soon as I closed flexVDIClient, the cpu felt down to 14%, so it looked like flexVDIClient was the problem. Then I started playing with it.
flexVDIClient´s main task is showing images of the remote console of a virtual machine, so the amount of computations per second it has to do depends on the amount of pixels it has to move to the local display. So my first tests involved resizing the client: when I made flexVDIClient only slightly smaller than the full screen, CPU usage went down to 20%, which looked quite good. Maybe it wasn´t flexVDIClient´s fault after all.
Window positioning seems to be the key
After changing the windows size, without affecting too much to CPU usage, I had to try something else. Then I started moving the window, and I noticed the following:
Let “x” be the distance (in pixels) from the left border of the big screen to the left border of flexVDIClient, with negative values indicating that part of the window is in the left screen:
-
x (windows position)
Total CPU use
-100, -4, -2, 0, 1, 2
45%
3, 4, 5
35%
> 6
15-18%
What?!
When flexVDIClient window is “close” to the left screen, up to 5 pixels away, CPU usage (by the “System” process) is high. But if all the window is inside the left screen, CPU usage is low again.
Taskbar transparency
I went on testing possible factors.
I found that it was not window position itself, but window position relative to Windows taskbar what caused the problem. If I moved the taskbar to the left side or to the top of the left screen, so that the window was not behind the taskbar, the high CPU usage disappeared.
But it is not the full taskbar what caused the problem. Just the “show desktop button” in the right side of the taskbar. And not even the whole button: the bottom part of this button does not present this effect. But a small area to the right (remember those 5 pixels in the table?) and to the left of this button does.
And if I put the big monitor with flexVDIClient left to the small screen with the taskbar, then CPU usage is high when flexVDIClient is next to the “Start button”. Go figure.
Transparency must be present too. If I disable transparency, CPU usage goes down.
Conclusions:
There seems to be a bug in Windows 7 when applying transparency around the left and right borders of the taskbar, at least on my machine. But there is not much I can do about it.
In general terms, transparency effects can cost a lot of CPU. I have seen more than 20% of my i5 continuously dedicated to transparency during these tests. If you want performance, disabling visual effects can give the machine a noticeable amount of extra power. Disabling “Use visual styles on windows and buttons” makes the trick too, as it does disabling “Visual Glass style”, or any other option in windows that removes transparency. You can find several of them under “Visual effects configuration”.
In the end I came up with a workaround. Now my Desktop is arranged like this:
Now the taskbar (bottom of the left screen) is below the right screen. So its sides do not “interfere” with the windows in the right screen, and CPU usage is normal again.