Notifications not always visible

[Nathan]

Sometimes, part of, or the whole notifiction does not show up, while hoovering over it, it becomes clearly visible.

Howto reproduce: to be honest: I have no idea
What seems to work (sometimes):
use notify-send to display a big image (in the screenshot a jpg of 40.5 kb with res 600x600px) and before it loads load a long loading page in firefox

on terminal : "sleep 4 && &notify-send "Title" "Body text" -i /path/to/big/image", go to firefox and load planet.ubuntu.com (for example)

I'm using metacity with compositor, notify-osd 0.9.20-0ubuntu1, latest karmic

[Nathan (nathansamson)]

A screenshot of the issue.

The text in the not is blurred in The gimp, because it was not suitable for publication...

[Mirco Müller (macslow)]

There's a typo in your initial bug-description. The (third) ampersand before the notify-send command is too much. Why do you use && there after sleep? A ; would be sufficient at that spot. Or do you expect the sleep command to fail?

Nevertheless, I've tried your described bug-reproduction-process multiple times and was not able to trigger the bug shown in your screenshot.

Apart form that, I've never seen such a rendering-bug of notify-osd myself yet. How often do you see this happening in general (e.g. out of 10 shown notifications how many fail)? What graphics-card (GPU) and driver do you use on your affected system? Can you try it with compiz and see if that bug is triggered there too?

[Nathan (nathansamson)]

There's a typo in your initial bug-description. The (third) ampersand before the notify-send command is too much. Why do you use && there after sleep? A ; would be sufficient at that spot. Or do you expect the sleep command to fail?

&& is just my way to chain commands, I guess ; is more common... ;)

I think I've found a more reliable way to reproduce this issue:
When CPU load is 100% the notifications doesn't show up most of the time, unless I hover over them, but only with metacity with compositor...

Howto reproduce:
* Start gnome-terminal, and open N tabs and start in each tab "while true; do ls -l *; done" (where N is the number of CPU's in your computer) -- Another way to reproduce high CPU is as good as this...
* Show some notificications (In this case, I used banshee and did next song, which shows a notification)
* See that in metacity without compositor and compiz everything works fine, in metacity with compositor most (80%) of the notifictions do not show up, or show up badly rendered (see screenshot), unless you hover over them.

I do have an intel 950 GM

[Nathan (nathansamson)]

The first 3 lines in last comment should be quoted...

I wonder why their is no way to edit your last comment...

[Mirco Müller (macslow)]

Even with a very high CPU-load (compiling compiz, while true...;) under metacity+compositor I can't force this rendering bug to happen. Doing this on an nvidia GPU (8800 GT) here. At the moment I don't have a intel GMA 950 based system at my disposal to try it there.

[Mirco Müller (macslow)]

From my recent testing with the nv-driver and metacity+compositor this seems to be a metacity-specfic issue. Bubbles are rendered by notify-osd, but metacity does not update the screen immediately. For example if a bubble does not show up as expected moving a window around in the area where the bubble should show up, causes metacity to update that part of the screen exposing the bubble. I expect this to be some XDamage/XFixes issue in metacity's code. There's nothing which could be done from within notify-osd to work around this case.