strange behaviour when resize windows

miro123 · 03-17-2020, 11:43 AM

Hello I am Miro from Slovakia. I have laptop dell latitude E6540.

Code:

System:    Host: mx Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
           root=UUID=0a98da4a-226b-4701-9a8f-67186a163d39 ro quiet splash 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel, plank wm: xfwm4 
           dm: LightDM 1.26.0 Distro: MX-19.1_x64 patito feo October 21  2019 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Laptop System: Dell product: Latitude E6540 v: 00 serial: <filter> Chassis: 
           type: 9 serial: <filter> 
           Mobo: Dell model: 0RHT9R v: A00 serial: <filter> UEFI: Dell v: A26 date: 10/09/2018 
Battery:   ID-1: BAT0 charge: 45.3 Wh condition: 45.3/66.6 Wh (68%) volts: 12.8/11.1 
           model: SMP DELL HTX4D2A type: Li-ion serial: <filter> status: Full 
CPU:       Topology: Dual Core model: Intel Core i5-4310M bits: 64 type: MT MCP arch: Haswell 
           family: 6 model-id: 3C (60) stepping: 3 microcode: 27 L2 cache: 3072 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 21550 
           Speed: 2880 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 3350 2: 3352 3: 3348 
           4: 3300 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
           STIBP: conditional, RSB filling 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Dell driver: i915 
           v: kernel bus ID: 00:02.0 chip ID: 8086:0416 
           Display: x11 server: X.Org 1.20.4 driver: intel compositor: compton 
           v: 0.1~beta2+20150922 resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 19.3.3 compat-v: 3.0 
           direct render: Yes 
Audio:     Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio vendor: Dell 
           driver: snd_hda_intel v: kernel bus ID: 00:03.0 chip ID: 8086:0c0c 
           Device-2: Intel 8 Series/C220 Series High Definition Audio vendor: Dell 
           driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:8c20 
           Sound Server: ALSA v: k4.19.0-6-amd64 
Network:   Device-1: Intel Ethernet I217-LM vendor: Dell driver: e1000e v: 3.2.6-k port: f080 
           bus ID: 00:19.0 chip ID: 8086:153a 
           IF: eth0 state: down mac: <filter> 
           Device-2: Qualcomm Atheros AR9485 Wireless Network Adapter vendor: Dell driver: ath9k 
           v: kernel port: f040 bus ID: 03:00.0 chip ID: 168c:0032 
           IF: wlan0 state: up mac: <filter> 
Drives:    Local Storage: total: 447.13 GiB used: 36.36 GiB (8.1%) 
           ID-1: /dev/sda vendor: Kingston model: SA400S37480G size: 447.13 GiB block size: 
           physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: B1C3 scheme: GPT 
RAID:      Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci v: 3.0 
           port: f060 bus ID: 00:1f.2 chip ID: 8086.282a rev: 04 
Partition: ID-1: / raw size: 80.32 GiB size: 78.81 GiB (98.12%) used: 36.36 GiB (46.1%) fs: ext4 
           dev: /dev/sda5 
           ID-2: swap-1 size: 9.77 GiB used: 0 KiB (0.0%) fs: swap swappiness: 15 (default 60) 
           cache pressure: 100 (default) dev: /dev/sda6 
Sensors:   System Temperatures: cpu: 46.0 C mobo: 43.0 C sodimm: 33.0 C 
           Fan Speeds (RPM): cpu: 0 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/google-chrome.list 
           1: deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mxrepo.com/mx/repo/ buster main non-free
           2: deb http://mxrepo.com/mx/repo/ buster ahs
           Active apt repos in: /etc/apt/sources.list.d/opera-stable.list 
           1: deb https://deb.opera.com/opera-stable/ stable non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
           Active apt repos in: /etc/apt/sources.list.d/vscode.list 
           1: deb [arch=amd64] http://packages.microsoft.com/repos/vscode stable main
Info:      Processes: 247 Uptime: 28m Memory: 7.70 GiB used: 1.82 GiB (23.7%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: quick-system-in inxi: 3.0.36

I installed mx linux 19.
I see strange behavior when resizing windows and I have a relatively high CPU usage.

I discussed this on the MX Linux Forum.
link to diskusion: https://forum.mxlinux.org/viewtopic....aviour#p552402

Is it some bug?

I did everything they advised me, but it didn't help.
Can you help me?

frankbell · 03-18-2020, 08:08 PM

I just did some experiments in a Slackware --Current VM with XFCE with 4 GB RAM.

When I resized a window simply (that is, I just changed it to a different size), RAM usage spiked to 30-40%. When energetically resized it (that is, I grabbed corner and wiggled it around before settling on a size), usage spiked to 80-90%, but immediately subside once the moving was done.

If this is sort of behavior you are concerned about, I wouldn't be alarmed.

Just my opinion.

Welcome to LQ.

rnturn · 03-18-2020, 08:41 PM

Quote:

Originally Posted by frankbell

I just did some experiments in a Slackware --Current VM with XFCE with 4 GB RAM.

When I resized a window simply (that is, I just changed it to a different size), RAM usage spiked to 30-40%. When energetically resized it (that is, I grabbed corner and wiggled it around before settling on a size), usage spiked to 80-90%, but immediately subside once the moving was done.

If this is sort of behavior you are concerned about, I wouldn't be alarmed.

I have Slackware + Xfce on my laptop and haven't noticed this though I can't say I've paid it much attention. The OP's CPU use shows up on openSUSE + KDE as well (it's actually hitting both cores on my desktop). I've noticed that most windowing managers seem to default to displaying the window content while it's being resized---not sure if Xfce is one of those. I can easily imagine this chewing up a lot of CPU while the contents are repeatedly rescaled, text rewrapped, etc., while the window size is changing. If you can turn that behavior off -- showing the new window edges while resizing and only redisplaying the contents when the edge/corner is released -- you'd reduce the CPU load quite a bit.

frankbell · 03-18-2020, 09:13 PM

Quote:

I've noticed that most windowing managers seem to default to displaying the window content while it's being resized---not sure if Xfce is one of those.

It indeed is.

ondoho · 03-19-2020, 03:22 AM

Quote:

Originally Posted by rnturn

If you can turn that behavior off -- showing the new window edges while resizing and only redisplaying the contents when the edge/corner is released -- you'd reduce the CPU load quite a bit.

This is possible with XFCE in Settings => Window Manager => Advanced => Hide contents of windows.
If the CPU struggles it might also be advisable to turn off compositing.