PR 41 Thumbnail for iconized windows: growing cpu usage

[vredesbyyrd]

In reference to #41

I did run into an issue, but I have no idea on how to track down where its happening.

The cpu usage of the Xorg process slowly grows on each invocation of skippy. The skippy process does not grow, it hovers betweeen 0.0 and 0.1.

EDIT:

Removed reference to:

cpu usage only seems to grow when using the showAllDesktops = true config option. That does not seem to hold true after more testing.

But, showAllDesktops does appear to make the "bug" worse, ie raise cpu usage higher and quicker to the (10%+) range.

I start skippy in daemon mode:

skippy-xd-runner --config /home/clu/.config/skippy-xd/skippy-xd.rc --start-daemon

And activate it with:

skippy-xd-runner --activate-window-picker

Activating the window picker 15-20 times the Xorg cpu usage grows from about 0.2% to a steady 10.0%. Killing the skippy daemon drops cpu back to 0.2.

I don't believe there is anything enlightening in the skippy output, but i will post some below, just in case. If you have any ideas on debugging on my end, please let me know.

EDIT:

A quick note, it seems to grow much quicker with my external display connected (which was attached in my initial comment). I'll have to test more tomorrow.

On start:

config_load(): config file found. using "/home/clu/.config/skippy-xd/skippy-xd.rc"
parse_pict_posp_mode("#161616"): Unrecognized operation.
parse_align("#161616"): Unrecognized operation.
wm_check(): Your WM is neither EWMH nor GNOME WM compliant. Troubles ahead.
main(): Running as daemon...
main(): Finished flushing pipe "/tmp/skippy-xd-fifo".
xerrorerror 143 (BadPicture) request 139 minor 8 serial 312 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 313 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 343 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 344 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 380 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 381 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 412 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 413 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 448 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 449 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 479 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 480 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 516 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 517 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 549 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 550 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 579 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 580 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 617 ("RenderBadPicture (invalid Picture parameter)")

xerrorerror 143 (BadPicture) request 139 minor 8 serial 618 ("RenderBadPicture (invalid Picture parameter)")

[     4.14 ] [     4.14 ] [     4.15 ] [     4.15 ] [     4.15 ] [     4.15 ] [     4.48 ] [     4.48 ] [     4.49 ] [     4.49 ] [     4.79 ] [     4.79 ] [     4.79 ] [     4.79 ] [     5.33 ] [     5.33 ] [     5.33 ] [     5.33 ] [     5.33 ] [     5.33 ] mainloop(): Received pipe command: 1
mainloop(): case PIPECMD_ACTIVATE_WINDOW_PICKER:
mainloop(): activate = true;
mainloop(): PIPEHUP on pipe "/tmp/skippy-xd-fifo".

xerrorerror 8 (BadMatch) request 42 minor 0 serial 6536 ("BadMatch (invalid parameter attributes)")

[    25.23 ] 

Each invocation thereafter:

mainloop(): Received pipe command: 1
mainloop(): case PIPECMD_ACTIVATE_WINDOW_PICKER:
mainloop(): activate = true;
mainloop(): PIPEHUP on pipe "/tmp/skippy-xd-fifo".

xerrorerror 8 (BadMatch) request 42 minor 0 serial 13604 ("BadMatch (invalid parameter attributes)")

[    29.53 ] 

CONFIG:

[general]
distance = 50
useNetWMFullscreen = true
ignoreSkipTaskbar = false
updateFreq = 60.0
animationDuration = 225 # set = 0 to switch off animations
lazyTrans = false
background = #161616
movePointerOnStart = true
movePointerOnSelect = true
movePointerOnRaise = true
switchDesktopOnActivate = true
#useNameWindowPixmap = false
#forceNameWindowPixmap = false
includeFrame = false
allowUpscale = true
showAllDesktops = true
#showUnmapped = true
preferredIconSize = 48
clientDisplayModes = thumbnail zombie
iconFillSpec = orig mid mid #00FFFF
fillSpec = orig mid mid #FFFFFF
background = #DFDFDF

[xinerama]
showAll = true

[normal]
tint = black
tintOpacity = 0
opacity = 255

[highlight]
tint = blue
tintOpacity = 0
opacity = 215

[tooltip]
show = false
followsMouse = true
offsetX = 0
offsetY = 30
align = mid
border = #101619
background = #101619
opacity = 128
text = #7D95A0
textShadow = none
font = fixed-9:weight=bold

[bindings]
miwMouse1 = focus
miwMouse2 = close-icccm
miwMouse3 = close-icccm
keysUp = Up w
keysDown = Down s
keysLeft = Left a
keysRight = Right d
keysPrev = p b
keysNext = n f
keysExitCancelOnPress = Escape BackSpace x q
keysExitCancelOnRelease =
keysExitSelectOnPress = Return space
keysExitSelectOnRelease = Super_L Super_R Alt_L Alt_R ISO_Level3_Shift
keysReverseDirection = Tab
modifierKeyMasksReverseDirection = ShiftMask ControlMask

[vredesbyyrd]

@felixfung

thanks for the feedback. Wondering if the issue is the same if you don't use skippy-runner, and directly do skippy-xd --start-daemon?

Good question, unfortunately though the behavior is the exact same. I always only used skippy-xd to start the program/daemon. But in trying to narrow down the issue I figured I should try skippy-xd-runner.

EDIT:

I have a few different window managers installed, so shortly here I will see if I can reproduce the issue on those, at least try and rule out it being a 2bwm problem.

[vredesbyyrd]

After some more testing I am fairly confident it has something to do with the compositor, picom (formally compton). Running without the compositor the cpu climbing issue never occurs, so I am trying to find a way to exclude skippy from all compositing.

[felixfung]

After some more testing I am fairly confident it has something to do with the compositor, picom (formally compton). Running without the compositor the cpu climbing issue never occurs, so I am trying to find a way to exclude skippy from all compositing.

Interesting, I am using picom and I do not experience CPU climb?

[felixfung]

Will look into this more...

[vredesbyyrd]

Yeah agreed, it is strange. Here is my picom config...warning though, its a total mess from over the years. I need to clean it up sooner than later. I am not using any fancy features eg blur, shadows.

EDIT:

Running picom with default config: picom --config /etc/xdg/picom.conf --backend glx does not make a difference.

[vredesbyyrd]

Along with the compositor, it seems it may be tied to video eg mpv/youtube, at the least video makes the issue more prominent.

Example:

• Video playing + skippy running = xorg cpu +10%
• Pause video and cpu drops to normal
• Unpause video and cpu jumps back up to +10%
• Kill skippy and xorg cpu drops to less than 1% while video is still playing.

In summary - its strange behavior and I am pretty stumped.

[felixfung]

I just did a quick test, for me, both with and without skippy daemon, and skippy may be active or not, with movie playing the movie player takes 15-20% CPU, and Xorg takes around 10% CPU.

This problem might be multi-factorial, including hardware or hardware acceleration, or related to #52... I don't have much knowledge on X or composition or hardware acceleration at all, so debugging this might take a while...

But much appreciated for your reporting and definitely we will be working on this.

[vredesbyyrd]

So I did not try this until now because of naive assumptions, but when disabling the animation, animationDuration = 0, I am unable to reproduce the issue. xorg cpu usage stays below 1% (0.2-0.8). Hmm.

[dreamcat4]

@vredesbyyrd FYI - it has been merged into master now. For example if you want to update skippy to latest version. The code for iconized windows is the same, (so is not expected to be any different behaviour here WRT this issue)

[felixfung]

@vredesbyyrd can you see if #57 improves the issue?

[vredesbyyrd]

After some testing, #57 does not help :/ I observed it did seem take more invocations for the xorg process to start climbing, but ultimately it still does. My system is not crazy powerful, but its not a hog either, Intel i5-8350U (8) @ 3.600GHz.

It took 30-40 invocations for xorg process to be using 10% cpu (measured using bottom), and at that point switching desktops/opening closing windows starts to glitch a bit.

I really do wonder if there is some bad interaction going on between skippy and the compositor (picom), or multi-factorial like you stated.

Personally, i do not need to use animations, but I will gladly keep testing any changes. And I may dig around picom a bit more again.

[felixfung]

I suspect for the iconized pixmaps I am not doing it right, leading to the high CPU usage in your case, and I guess there may be memory leak also...

This is a high priority bug and will be taken seriously. Thank you for reporting.

[vredesbyyrd]

I might have saw a relatively small increase in memory, but cannot be sure. I will take a closer look at memory.

This is a high priority bug and will be taken seriously. Thank you for reporting.

No problem, and thank you for your continued work on skippy, the animations do look great!

[felixfung]

Hi @vredesbyyrd just want to confirm you are still experiencing the same issue?

[vredesbyyrd]

Hi @felixfung my build is 5ish days old so missing some of the latest commits, i'll build from master tomorrow and get back to you asap.

[vredesbyyrd]

@felixfung

Unfortunately, still happening. As before - it may take a bit longer / more invocations to get the xorg cpu > 10%, but it still climbs.

And just as a reminder, this issue does not occur with animationDuration = 0 as stated in a previous comment. Wish I had better news for you!

[felixfung]

Yeah I didn't expect the issue to be fixed, but was asking just in case.

I'll continue working on it.

[felixfung]

@vredesbyyrd to be honest I don't have too much idea for now...

I notice your log has this line: wm_check(): Your WM is neither EWMH nor GNOME WM compliant. Troubles ahead.

Do you have another WM which is EWMH or GNOME compliant that you can try if it has the same performance bug?

Also perhaps you can use the improved logging from #83 to see if the detailed logs shed any more clue...

[vredesbyyrd]

I'll try on different window managers + the improved logging from #83

[felixfung]

@vredesbyyrd wondering if you still experience this?

[vredesbyyrd]

So I have not built from master in awhile so I just recompiled now. On 2bwm I can't seem to get the overview (expose, paging) to display at all. This is using an up to date default config file.

Start daemon:

skippy-xd --config /home/clu/.config/skippy-xd/skippy-xd.rc --start-daemon -S

Call skippy:

skippy-xd --expose

Daemon output:

config_load(): config file found. using "/home/clu/.config/skippy-xd/skippy-xd.rc"
check_modmasks(): ShiftMask  1 (0x01)
check_modmasks(): ControlMask  4 (0x04)
main(): after 2nd pass:  ps->o.focus_initial =  0
wm_check(): Your WM is neither EWMH nor GNOME WM compliant. Troubles ahead.
modkeymasks_str_enums(): ShiftMask  1 (0x01)
modkeymasks_str_enums(): ControlMask  4 (0x04)
keysyms_arr_keycodes(): i=0, keysym=65362, keycode=(0x111)
keysyms_arr_keycodes(): i=1, keysym=119, keycode=(0x25)
keysyms_arr_keycodes(): i=0, keysym=65364, keycode=(0x116)
keysyms_arr_keycodes(): i=1, keysym=115, keycode=(0x39)
keysyms_arr_keycodes(): i=0, keysym=65361, keycode=(0x113)
keysyms_arr_keycodes(): i=1, keysym=97, keycode=(0x38)
keysyms_arr_keycodes(): i=0, keysym=65363, keycode=(0x114)
keysyms_arr_keycodes(): i=1, keysym=100, keycode=(0x40)
keysyms_arr_keycodes(): i=0, keysym=112, keycode=(0x33)
keysyms_arr_keycodes(): i=1, keysym=98, keycode=(0x56)
keysyms_arr_keycodes(): i=0, keysym=65289, keycode=(0x23)
keysyms_arr_keycodes(): i=1, keysym=110, keycode=(0x57)
keysyms_arr_keycodes(): i=2, keysym=102, keycode=(0x41)
keysyms_arr_keycodes(): i=0, keysym=65307, keycode=(0x09)
keysyms_arr_keycodes(): i=1, keysym=65288, keycode=(0x22)
keysyms_arr_keycodes(): i=2, keysym=120, keycode=(0x53)
keysyms_arr_keycodes(): i=3, keysym=113, keycode=(0x24)
keysyms_arr_keycodes(): i=0, keysym=65293, keycode=(0x36)
keysyms_arr_keycodes(): i=1, keysym=32, keycode=(0x65)
keysyms_arr_keycodes(): i=0, keysym=65515, keycode=(0x133)
keysyms_arr_keycodes(): i=1, keysym=65516, keycode=(0x134)
keysyms_arr_keycodes(): i=2, keysym=65513, keycode=(0x64)
keysyms_arr_keycodes(): i=3, keysym=65514, keycode=(0x108)
keysyms_arr_keycodes(): i=4, keysym=65027, keycode=(0x92)
keysyms_arr_keycodes(): i=0, keysym=65289, keycode=(0x23)
main(): Running as daemon...
main(): Finished flushing pipe "/tmp/skippy-xd-fifo-3".
wm_get_stack_sub(): Retrieved window stack by querying all children.
daemon_count_clients(): No client windows found.
mainloop(): Received pipe command: 3
mainloop(): skippy activating, mode=1
mainloop(): activate = true;
wm_get_focused(): Parent window of 0x03000003 is 0x000007b6.
wm_get_stack_sub(): Retrieved window stack by querying all children.
daemon_count_clients(): No client windows found.
mainloop(): PIPEHUP on pipe "/tmp/skippy-xd-fifo-3".

The overview/expose is never shown. The obvious answer is wm_check(): Your WM is neither EWMH nor GNOME WM compliant. Troubles ahead., regardless skippy always worked fine on previous builds with exception of animation=true.

So currently I cannot test whether the animation bug is still present on 2bwm/my daily driver. I just tested on gnome and skippy appears to work fine. I cannot reproduce the "growing cpu" issue on gnome which tells me its something with 2bwm. I would be fine with closing this issue since the bug appears wm specific, although it would be nice to be able to at least test on 2bwm on the a current build.

[felixfung]

@vredesbyyrd can you please try enabling _NET_CLIENT_LIST and _WIN_CLIENT_LIST by removing these two lines: https://github.com/dreamcat4/skippy-xd/blob/b158114ad68d62493dc3e6a458f8a5d4e713a8fa/src/wm.c#L347 https://github.com/dreamcat4/skippy-xd/blob/b158114ad68d62493dc3e6a458f8a5d4e713a8fa/src/wm.c#L361

And see if it works on 2bwm or not?

[vredesbyyrd]

Enabling _NET_CLIENT_LIST and _WIN_CLIENT_LIST made it work on 2bwm again. If there is a downside to having that enabled in the master branch I can just build it with a patch for personal use.

Regarding cpu issue while animations are enabled - It does appear significantly better. Without a video playing (video seemed to be a trigger in the past) I could not reproduce the issue. With video playing it took 40+ consecutive calls to skippy to get the xorg cpu process > 3-5%.

Life got busy recently and I have not been following skippy development much so I do not know what changes have been made (it appears to be a lot though!)...personally I'd say this issue is resolved or at least good enough.

One more thing of note - on 2bwm switch to desktop on activate does not work on the latest build. I noticed the config option switchDesktopOnActivate was removed, I assume it's supposed to be default behavior now. I can make a separate issue need be. The error returned is:

xerror(): error 8 (BadMatch) request 42 minor 0 serial 114653 ("BadMatch (invalid parameter attributes)")

[felixfung]

Enabling _NET_CLIENT_LIST and _WIN_CLIENT_LIST made it work on 2bwm again. If there is a downside to having that enabled in the master branch I can just build it with a patch for personal use.

I'll add the option back in... strange that 2bwm is not honouring XQueryTree() though. I am curious whether _NET_CLIENT_LISTand _WIN_CLIENT_LIST in 2bwm give the correct z-order? You can most easily check by playing around with the switch feature, whether window prev/next ordering should be identical to the window last focused ordering.

Regarding cpu issue while animations are enabled - It does appear significantly better. Without a video playing (video seemed to be a trigger in the past) I could not reproduce the issue. With video playing it took 40+ consecutive calls to skippy to get the xorg cpu process > 3-5%.

Life got busy recently and I have not been following skippy development much so I do not know what changes have been made (it appears to be a lot though!)...personally I'd say this issue is resolved or at least good enough.

I never understood this performance bug, and why it has improved over time (my own experience as well). What if you try reducing updateFreq to different values? Would that reduce this issue even more?

One more thing of note - on 2bwm switch to desktop on activate does not work on the latest build. I noticed the config option switchDesktopOnActivate was removed, I assume it's supposed to be default behavior now. I can make a separate issue need be. The error returned is:

xerror(): error 8 (BadMatch) request 42 minor 0 serial 114653 ("BadMatch (invalid parameter attributes)")

I can fix this. But another curious point, you mean on 2bwm the window would focus but the desktop would not switch?

[vredesbyyrd]

I'll add the option back in... strange that 2bwm is not honouring XQueryTree() though. I am curious whether _NET_CLIENT_LISTand _WIN_CLIENT_LIST in 2bwm give the correct z-order? You can most easily check by playing around with the switch feature, whether window prev/next ordering should be identical to the window last focused ordering.

Regarding XQueryTree(), a very naive assumption is 2bwm uses xcb as opposed to xlib. A cursory glance at the xcb doc lists a xcb_query_tree function. Awesome window manager is another xcb wm. I know next to nothing about X11 protocols though.

What if you try reducing updateFreq to different values? Would that reduce this issue even more?

Good thought - i'll give it try just to test out that theory.

I can fix this. But another curious point, you mean on 2bwm the window would focus but the desktop would not switch?

Yes, although I cannot be sure the window is actually grabbing focus, I'd assume not. I select a window thats in another workspace, but the workspace does not get switched to. Skippy just closes on the same workspace it was called from.

[felixfung]

@vredesbyyrd please try out #139 and #140, which is already merged into master

[vredesbyyrd]

Thank you. _NET_CLIENT_LIST config option works appropriately on 2bwm. Switching workspaces also now works.