[opensuse-support] X takes too much CPU when the screen of xfreerdp is heavily updated
Hi there, I used xfreerdp to connect to a Windows 7 desktop to do some work. When the screen from that desktop has something to keep updating, such as the busily refreshed highlighting of elements in a 3D model, the X process in my openSUSE desktop takes full CPU time of a core. The options I used for `xfreerdp` are like these, ``` /rfx /jpeg-quality:60 /codec-cache:rfx /audio-mode:2 -wallpaper +clipboard +compression /size:1366x1024 /bpp:16 ``` And I am using KDE on Tumbleweed and all related packages are from OSS. Is that normal? Cheers, Zeng -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On lundi, 4 juin 2018 10.11:41 h CEST H Zeng wrote:
Hi there,
I used xfreerdp to connect to a Windows 7 desktop to do some work. When the screen from that desktop has something to keep updating, such as the busily refreshed highlighting of elements in a 3D model, the X process in my openSUSE desktop takes full CPU time of a core.
The options I used for `xfreerdp` are like these, ``` /rfx /jpeg-quality:60 /codec-cache:rfx /audio-mode:2 -wallpaper +clipboard +compression /size:1366x1024 /bpp:16 ```
And I am using KDE on Tumbleweed and all related packages are from OSS.
Is that normal?
Cheers, Zeng
What top is telling you, in my case pulseaudio get the load due to the redirection. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Monday, 4 June 2018 10:42:02 BST Bruno Friedmann wrote:
What top is telling you, in my case pulseaudio get the load due to the redirection.
Thanks Bruno. It's just `X`, nothing else. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am 04.06.2018 um 10:11 schrieb H Zeng:
Hi there,
I used xfreerdp to connect to a Windows 7 desktop to do some work. When the screen from that desktop has something to keep updating, such as the busily refreshed highlighting of elements in a 3D model, the X process in my openSUSE desktop takes full CPU time of a core.
The options I used for `xfreerdp` are like these, ``` /rfx /jpeg-quality:60 /codec-cache:rfx /audio-mode:2 -wallpaper +clipboard +compression /size:1366x1024 /bpp:16 ```
And I am using KDE on Tumbleweed and all related packages are from OSS.
Is that normal?
Cheers, Zeng
I've seen high cpu usage in xfreerdp, when the app on the remote site made use of GPU acceleration; in my case it was firefox. One option, you could try, is : /network:auto I got this recommendation from the upstream developers, but don't expect any miracles. Hendrik -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Monday, 4 June 2018 17:22:25 BST Hendrik Woltersdorf wrote:
I've seen high cpu usage in xfreerdp, when the app on the remote site made use of GPU acceleration; in my case it was firefox.
Thank you, Hendrik. That makes sense because I was doing some CAD operations that caused much screen refreshing/updating.
One option, you could try, is : /network:auto I got this recommendation from the upstream developers, but don't expect any miracles. Do you mean that my local machine was struggling to keep up with the updated screen? I tried the option but no effect.
I heard that xfreerdp transfers screen as screenshots from remote to local and displays them for local screen. Maybe the problem is that `X` takes too much resource to show the images? -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 05/06/18 07:14, H Zeng wrote:
On Monday, 4 June 2018 17:22:25 BST Hendrik Woltersdorf wrote:
I've seen high cpu usage in xfreerdp, when the app on the remote site made use of GPU acceleration; in my case it was firefox.
Thank you, Hendrik. That makes sense because I was doing some CAD operations that caused much screen refreshing/updating.
One option, you could try, is : /network:auto I got this recommendation from the upstream developers, but don't expect any miracles. Do you mean that my local machine was struggling to keep up with the updated screen? I tried the option but no effect.
I heard that xfreerdp transfers screen as screenshots from remote to local and displays them for local screen. Maybe the problem is that `X` takes too much resource to show the images?
Yep, generally large screen updates like this can be done with opengl which transfers most of the CPU load to the GPU (even in the case of playing video etc), whereas in this case each image is being decoded over the network via the CPU which is why it comes under significant load. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tuesday, 5 June 2018 01:32:58 BST Simon Lees wrote:
On 05/06/18 07:14, H Zeng wrote:
On Monday, 4 June 2018 17:22:25 BST Hendrik Woltersdorf wrote:
I've seen high cpu usage in xfreerdp, when the app on the remote site made use of GPU acceleration; in my case it was firefox.
Thank you, Hendrik. That makes sense because I was doing some CAD operations that caused much screen refreshing/updating.
One option, you could try, is : /network:auto I got this recommendation from the upstream developers, but don't expect any miracles.
Do you mean that my local machine was struggling to keep up with the updated screen? I tried the option but no effect.
I heard that xfreerdp transfers screen as screenshots from remote to local and displays them for local screen. Maybe the problem is that `X` takes too much resource to show the images?
Yep, generally large screen updates like this can be done with opengl which transfers most of the CPU load to the GPU (even in the case of playing video etc), whereas in this case each image is being decoded over the network via the CPU which is why it comes under significant load.
Thank you, Simon. I guess this is normal, then. Best regards, Zeng -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (4)
-
Bruno Friedmann -
H Zeng -
Hendrik Woltersdorf -
Simon Lees