notify-osd is losing performance

[manzur]

Distribution: Ubuntu 9.10 alpha 2 with latest updates
this is horrible because it stays glowing for a long time if a leave volume key pressed
http://www.youtube.com/watch?v=UU7aNOaUZfE
it should glow once and that should be it, not many time, i have to wait until it stops to volume down again.

[Mirco Müller (macslow)]

Do you press Volume-Up/Down or do you use the Volume-Mute key? What GPU do you have installed? Which driver (proprietary or OpenSource one)? Do you use compiz or metacity? What exactely takes one second... the first bubble showing up? Is this the first notification showing up after loggin in/booting up?

[manzur (sl-solaris)]

At first i use the Volume-Mute key, because i have a problem with alsa driver so i have to mute it (this is how i realized aout this bug with notifications) but when I press Volume-Up/Down it is the same, it take like 1 sec to show up, so for example if i press volume-up and then volume-down, it take 1 sec to show me volume-up notification and after 1 second more it shows me volume-down notification, it is horrible!..

At frirst I thought it was because of compiz and my proprietary driver (NVidia) but i switch to metacity with no compositing and it last the same to show-up, so it is not because of compiz or any proprietary driver

[Tobias Wolf (towolf)]

For me the glowing effect when the scale hits 100% is very slow on intel.

[manzur (sl-solaris)]

i think that notify-osd should detect when another process of the same category is activated, so it will replace the last one for the new one and when it is something different it should show another notification below, for example:
when we volume down and next volume up it should replace the last notification for the new one as fast as possible, do u understand me?, but when we volume up and some contact in our mailing list send us a message the last notification (volume up) should stay and show the other notification (the message) below this one.

i think this is the way this should work, the second part is actually working like this, but the first idea (replacing last notification of the same category as it is volume-up and down) is not yet implemented, so, this is my feedback and god bless u guys!!!!

[mannheim (kronheim)]

I'm not sure if the following is the same slowness that the original bug describes, but I experience this. With Ubuntu 9.04 on Dell laptop with intel graphics, do the following:

1. Press and hold the "volume-up" button. Hold it long enough for the key auto-repeat to register more than 20 repeats, say.

2. Release the volume-up button.

3. Watch the volume on-screen-display. It slowly, slowly responds to each on one of those 20 repeats. Each response takes about 1/2 to 1 second. Each response is not smooth (the osd is supposed to "glow" up and down, but it changes in irregular steps). You can sit and watch it for 15 seconds.

4. During all this time "top" shows that notify-osd is using about 89% of one of the two CPU cores.

This happens both with metacity and with compiz.

It really makes the volume-control on my laptop completely unusable. The user needs to be able to press and hold the button and simply release the button when the volume is at the desired level. This is impossible because of the slow response to each key-repeat.

[Mirco Müller (macslow)]

The blur-cache is missing still in notify-osd. Once that implemented this lag will no longer occur.

[manzur (sl-solaris)]

 @mannheim, it is exactly what is happening to me, when I hold volume-up key on my keyboard for a while and then I release it, it begins to light up a lot of times, it is horrible, i would like to upload a video, let me see if I can do it

[manzur (sl-solaris)]

http://www.youtube.com/watch?v=UU7aNOaUZfE

[Mirco Müller (macslow)]

manzur, thanks for the video. It confirms my assumption. With the blur/surface-cache, meant to land in notify-osd by the time Karmic hits, this should be solved. Apart form that, "spam-protection" in the queue-handling of notify-osd will also help ease the flood of these feedback-notifications (also called synchronous notifications).

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

So does this mean that there will be more of an instant response to changing volume? There's a small delay when raising and lowering the volume that, while not terrible, does get slightly annoying.

[manzur (sl-solaris)]

i opened another bug report because i thought nobody was woking with this one: https://bugs.launchpad.net/bugs/392167

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

As of Koala alpha 5, I still have clunky volume control.

I have a dell keyboard with a little knob that I can turn. If I turn it too fast, it will get extremely sluggish, and, if I have other processes occurring, will slow down my computer significantly. It gets even worse if I turn it the other way afterward (as I sometimes do by accident when I let go; it's sensitive to touch).

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

http://dl.getdropbox.com/u/373797/out.ogv

This demonstrates Karmic A5. These raisings and lowerings are extremely sluggish. The video may make it seem like I'm adjusting it and it's responsive for the most part, but I am raising and lowering the volume at a fairly speedy pace (which is what a normal user would do - In Windows on this keyboard, it's INSTANT and reliable)

[xax200 (jacobguy3)]

I can also confirm this bug. Raising and lowering volumes on compiz and metacity are sluggish.

My system is:
1.8 Ghz
1 Gb ram
Ubuntu Karmic Alpha 5
notify-osd 0.9.21-0ubuntu2

[manzur (sl-solaris)]

it persist in karmic alpha 6.. when i thought it was completely fixed

[That Bum (jzachariou)]

Also persists in Karmic Beta! At least on my machine, what with it's Pentium D and 8500GT. I don't think there's anything else that is affected in notify-osd, as I haven't come across any other notification that responds to input like volume-control.

I don't really think this is a graphical issue, but some kind of an input lag, also on my machine as far as I know. The CPU problem exists, it's around 60% for notify-osd. I tried the test above to reproduce the bug (by mannheim) and got the expected result.

Maybe it's specifically input device related, and there are some wonky drivers for particular multimedia keys on some keyboards. I have a Saitek Cyborg Keyboard with one of those heat-sensitive switches that aren't really switches, to control volume. Report your keyboards to try to find some sort of pattern.

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

I found it to be slightly better, but it does need to be improved still. It's still quite sluggish for adjusting volume quickly. The type of action that the person that submitted the bug report no longer affects me (holding the volume key for a while and watching it max forever and ever).

[Mirco Müller (macslow)]

I started work on a branch to further improve performance-bottlenecks. See lp:~macslow/notify-osd/conditional-bubble-refresh

[Dana Goyette (danagoyette)]

My (HP laptop) keyboard also causes the lag on notify-osd, and it's particularly bad when at minimum or maximum volume -- it's actaully faster to kill notify-osd than to wait for it to stop spazzing.

I have attached a log of my keyboard behavior ( xev | grep --line-buffered KeyPress | ts %.S | tee keyrepeat.log ) -- as you'll see, it repeats every 0.05 (1/20) second or so. It seems notify-osd can't cope with this rate of key repeats... and because notify-osd lags at displaying the volume change, the sound volume itself lags at changing. That's an entirely different issue, however (and it's synchronous "by design").

[Corey Kearney (snkiz-deactivatedaccount)]

This is the bug I filed seems similar. https://bugs.launchpad.net/notify-osd/+bug/484261 I found changing the priority of notify-osd helps alot

[Mirco Müller (macslow)]

There is a performance-tweak coming as part of an karmic-SRU for notify-osd, which should fix this issue.

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

Hi, Mirco, is there a scheduled time for this SRU to come in? No pressure, but all these milestone changes and such are a little confusing.

[Mirco Müller (macslow)]

As of notify-osd 0.9.26 this issue is fixed.