Long startup time

[onli]

When starting skippy-xd with first skippy-xd --start-daemon, then skippy-xd-activate (is that the theoretically best way?), it takes up to three seconds till the expose-view appears. The strange thing is, that it is not always like that - sometimes it is instant. But if it is instant, it is always that way, till I restart compton. I can't nail down what is causing this.

I'm using icewm and compton with an AMD-Gpu.

Let me know which information you need.

[richardgv]

Sorry for the very late reply...

I tried with icemw-1.3.8 and couldn't reproduce the issue. The problem is pretty hard to debug, so we may need some time.

1. Please firstly kill all possibly interfering applications (e.g. compositors, CPU/GPU-intensive apps).
2. Does the problem appear when you are not using daemon mode?
3. Do you see skippy-xd printing anything strange out?
4. When you execute skippy-xd --activate-window-picker, does the daemon print out mainloop(): Received pipe command: 1 immediately, or after 3 seconds? And is the subsequentwm_get_stack_sub(): Retrieved window stack from _NET_CLIENT_LIST. delayed?
5. Does closing all windows except your terminal help?
6. Does running with no configuration (skippy-xd --config /dev/null) help?
7. Do you see high CPU usage during the delay?
8. The most direct way to diagnose the problem is using a profiler. I would recommend callgrind (which comes with valgrind), but other profilers may work. You would need to compile skippy-xd with -O0 -g for debugging. The main window mapping code is in skippy_run_init(), so what takes the most time under it might be the source of the problem, and the call graph of mainloop() may worth investigation. callgrind doesn't consider the time waiting for response from X, so you may consider starting skippy-xd with -S.

... till I restart compton ...

Huh, what?! Did you mean skippy-xd or compton?

... (is that the theoretically best way?) ...

I suppose so.

[onli]

Thanks for your answer.

Huh, what?! Did you mean skippy-xd or compton?

Skippy-xd was slow and sometimes it seemed to help to restart the compositor.

I got the issue a bit further pinned down (and after writing this even more). When running compton, I switched from workspace to workspace and activated skippy. The delay only occured on the workspace running Firefox. Also, it is not only a delay, it is a freeze and sometimes everything is laggy after the skippy-windows appear.

I'm not sure if there is something specific to firefox, or that it is rendered as a way bigger window than the others. Strike that: Yes, it seems to be related to the window size, the size if not maximized. Geany can cause this as well when I make the window bigger. It is still not always though.

Now I killed compton and there was still a delay and lag, but only the first time.

Please firstly kill all possibly interfering applications (e.g. compositors, CPU/GPU-intensive apps).

There is only compton. Did it, seems definitely related.

Does the problem appear when you are not using daemon mode?

Yes.

Do you see skippy-xd printing anything strange out?

The output is always:

mainloop(): Received pipe command: 1 wm_get_stack_sub(): Retrieved window stack from _NET_CLIENT_LIST. mainloop(): PIPEHUP on pipe "/tmp/skippy-xd-fifo". [ 1492.91 ] error 8 (BadMatch) request 42 minor 0 serial 39647 ("BadMatch (invalid parameter > attributes)") clientwin_handle(): Quitting.

Normal?

does the daemon print out mainloop(): Received pipe command: 1 immediately, or after 3 seconds?

That is hard to tell because of the freeze, since the freeze prevents seeing that. I would say "after 3 seconds" then.

And is the subsequentwm_get_stack_sub(): Retrieved window stack from _NET_CLIENT_LIST. delayed?

That happened as well, but only one or three times. Normally not.

Does closing all windows except your terminal help?

Covered above, yes.

Does running with no configuration (skippy-xd --config /dev/null) help?

No.

Do you see high CPU usage during the delay?

Yes. Started skippy-xd when running compton, a big window and a terminal running htop, and there is definitely a spike in cpu-usage, up to 100% on core 1. The same when highlighting another window in skippy. Probably important: The process having the high CPU usage is X (I don't know if X aggreggates CPU usage caused by its clients, but I see no rise in the usage of skippy dameon (and can't see the skippy-xd-activate-process, probably to shortlived?), and not that high a rise in comptons usage).

Without compton, I still see a rise, but it is way less, only up to 35%, thus a smaller delay and no lag afterwards.

The most direct way to diagnose the problem is using a profiler.

If you after this response still think this would help, I can do this. I could also add debug-outputs to the code, if you have a hunch where this could be helpful (skippy_run_init()?).

[onli]

By now, I updated to Ubuntu 14.04. New software version, new driver version -> can't reproduce this anymore right now.

[richardgv]

Sorry for the late reply...

Thanks for the info. A big windows triggers the issue... Might be something related to X Render acceleration + X composite pixmap + X Render transform? Since the big main window skippy-xd creates doesn't trigger the issue and compton isn't freezing with large windows, either. Anyway, I'm glad that the issue is gone.

By the way, were you using radeon or the buggy fglrx? Would you mind telling us about the model of your graphic card / IGP? Just in case that would be helpful if somebody else encounters similar issues in the future.

[onli]

By the way, were you using radeon or the buggy fglrx?

If I remember correctly, fglrx. But I'm using fglrx right now as well, so that is not the cause (anymore, the driver is heavily developed right now anyway, I heard). The GPU is A Radeon HD 7850.

[richardgv]

If I remember correctly, fglrx. But I'm using fglrx right now as well, so that is not the cause (anymore, the driver is heavily developed right now anyway, I heard).

Thanks for the info. Actually the driver may be the reason if it is updated during/after your Ubuntu update.