Bug 390711

Seen this as well; but this is not Fedora specific, thus I think that's best
tracked and fixed directly upstream. I forwarded the problem to upstream's
bugtracker:

https://savannah.nongnu.org/bugs/index.php?21618

Upstream seems to belive that is okay:
https://savannah.nongnu.org/bugs/?20214

I agree that the situation could be improved, but I don't have the skills for
that and I think it should be done upstream in any case, as that is nothing
Fedora specific. Thus closing this here.

And how is that normal?

nm-tooltips is based on an old gtktooltips.  The current gtktooltips does seem
to have the same '#define DEFAULT_DELAY 500' but I can't see that it's used
anywhere for setting a timeout (just for setting member data that is not
referenced elsewhere).

So I think it's just that nm-tooltips.c needs porting to the newer GTK+
gtktooltips.c.

> Upstream seems to belive that is okay

I maintain another two packages from the same upstream. It is a good upstream,
there are good packages from it, but... the promotion of patches for this
upstream is... a little bit harder rather than could be expected.

If you believe me, than it is our task to fix this.

Reopen.

> So I think it's just that nm-tooltips.c needs porting to the newer GTK+
> gtktooltips.c.

Thorsten, (again :) ) show us the latest build logs. please.

(In reply to comment #3)
> And how is that normal?

The upstream author said that (you found it in the upstream bug) and he's not
CCed to this bug, so he can not answer your question.

(In reply to comment #4)
> nm-tooltips is based on an old gtktooltips.  The current gtktooltips does seem
> to have the same '#define DEFAULT_DELAY 500' but I can't see that it's used
> anywhere for setting a timeout (just for setting member data that is not
> referenced elsewhere).
> 
> So I think it's just that nm-tooltips.c needs porting to the newer GTK+
> gtktooltips.c.

Sounds good, but I don't have the skills for that, as I'm one of the fedora
package monkeys as dwmw2 calls them. And I actually think this isn't something
Fedora specific, that's why I think it should best dealt with upstream directly,
as that leads to improvements for everyone and avoids that work is done in
wasted because it's done in multiple places. 

I'm again willing to forward recent comments from this bug to the upstream bug
tracker, maybe the upstream author will then understand the issue better and
consider fixing it (maybe he did it already, there is no public devel repo).

I even would be a bit unwilling to ship a patch (if one would exists) for
anything else then testing purposes if there is no indication from upstream to
apply it sooner or later (similar how our kernel guys are unwilling to ship
patchs that are not heading upstream), thus I disagree with this:

(In reply to comment #5)
> If you believe me, than it is our task to fix this.

See also http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream 

If there is anything to improve that is not fedora-specific let's to it in a
coordinated way upstream please.

It has nothing to do with mn-tooltips. That timeout is a one-shot timeout. It is
caused by one or more of the following:

- MN updating the "Sent" time fields of the tooltip's mail summary. These fields
are updated every 500 milliseconds.
- If you're monitoring an Evolution mailbox, MN pinging Evo every second to
check if it's still running.
- If the icon is blinking because of an error, the 500 ms blink timeout (obviously).

I see nothing unnecessary in these actions.

(In reply to comment #7)
> It has nothing to do with mn-tooltips. That timeout is a one-shot timeout. It is
> caused by one or more of the following:
> 
> - MN updating the "Sent" time fields of the tooltip's mail summary. These fields
> are updated every 500 milliseconds.

This should only be updated when the tooltip is queried. It doesn't need to be
updated otherwise...

> - If you're monitoring an Evolution mailbox, MN pinging Evo every second to
> check if it's still running.

Evolution can also use D-Bus to tell your application that new mail has come in.
See the mail-notification plugin:
http://svn.gnome.org/viewvc/evolution/trunk/plugins/mail-notification/mail-notification.c?revision=34537&view=markup

You just need to check the folder URI or name to see if it pertains to you.

> - If the icon is blinking because of an error, the 500 ms blink timeout
(obviously).

That's obvious, but does it respect the GTK+ no-animation configuration option?

(In reply to comment #8)
> (In reply to comment #7)
> > It has nothing to do with mn-tooltips. That timeout is a one-shot timeout. It is
> > caused by one or more of the following:
> > 
> > - MN updating the "Sent" time fields of the tooltip's mail summary. These fields
> > are updated every 500 milliseconds.
> 
> This should only be updated when the tooltip is queried. It doesn't need to be
> updated otherwise...

GtkTooltip (which I will switch to in a couple of months, now that it supports
the "custom widget" feature that initially motivated my own tooltips fork) does
not provide a way to run code when the tooltip is shown or hidden. Even if it
did, it would be bad design to add code for suppressing the updates while the
tooltip is hidden, since these updates are extremely cheap.

> > - If you're monitoring an Evolution mailbox, MN pinging Evo every second to
> > check if it's still running.
> 
> Evolution can also use D-Bus to tell your application that new mail has come in.
> See the mail-notification plugin:
>
http://svn.gnome.org/viewvc/evolution/trunk/plugins/mail-notification/mail-notification.c?revision=34537&view=markup
> 
> You just need to check the folder URI or name to see if it pertains to you.

I have no idea what you are talking about nor why do you think that dbus could
lift the pinging requirement. That link points to an Evolution plugin which not
only does not use dbus, but also cannot be compared to MN: while that plugin
performs the notifications (popup and icon) itself, the MN plugin simply informs
MN (a standalone application) that a folder has changed.

> > - If the icon is blinking because of an error, the 500 ms blink timeout
> (obviously).
> 
> That's obvious, but does it respect the GTK+ no-animation configuration option?

What this has to do with the fact that making the icon blink involves running
code every 500 ms? By the way, it seems to me that blinking cannot be considered
an animation. GtkStatusIcon (which also supports blinking) does not respect that
setting either.

(In reply to comment #5)
> > Upstream seems to belive that is okay
> 
> I maintain another two packages from the same upstream. It is a good upstream,
> there are good packages from it, but... the promotion of patches for this
> upstream is... a little bit harder rather than could be expected.
> 
> If you believe me, than it is our task to fix this.

I imagine that you're talking about me, but unfortunately I've never received
any patch from you.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > It has nothing to do with mn-tooltips. That timeout is a one-shot timeout.
It is
> > > caused by one or more of the following:
> > > 
> > > - MN updating the "Sent" time fields of the tooltip's mail summary. These
fields
> > > are updated every 500 milliseconds.
> > 
> > This should only be updated when the tooltip is queried. It doesn't need to be
> > updated otherwise...
> 
> GtkTooltip (which I will switch to in a couple of months, now that it supports
> the "custom widget" feature that initially motivated my own tooltips fork) does
> not provide a way to run code when the tooltip is shown or hidden. Even if it
> did, it would be bad design to add code for suppressing the updates while the
> tooltip is hidden, since these updates are extremely cheap.

From the GtkTooltip docs:
"
Connect to the GtkWidget::query-tooltip signal. This signal will be emitted when
a tooltip is supposed to be shown. One of the arguments passed to the signal
handler is a GtkTooltip object. This is the object that we are about to display
as a tooltip, and can be manipulated in your callback using functions like
gtk_tooltip_set_icon(). There are functions for setting the tooltip's markup,
setting an image from a stock icon, or even putting in a custom widget.
"

So it's possible (and easy) to avoid wake-ups with the new tooltips. The fact
that they're "cheap" updates, I'm not denying, but they're also waking up the
process needlessly.

> > > - If you're monitoring an Evolution mailbox, MN pinging Evo every second to
> > > check if it's still running.
> > 
> > Evolution can also use D-Bus to tell your application that new mail has come in.
> > See the mail-notification plugin:
> >
>
http://svn.gnome.org/viewvc/evolution/trunk/plugins/mail-notification/mail-notification.c?revision=34537&view=markup
> > 
> > You just need to check the folder URI or name to see if it pertains to you.
> 
> I have no idea what you are talking about nor why do you think that dbus could
> lift the pinging requirement. That link points to an Evolution plugin which not
> only does not use dbus, but also cannot be compared to MN: while that plugin
> performs the notifications (popup and icon) itself, the MN plugin simply informs
> MN (a standalone application) that a folder has changed.

You're right, it doesn't use D-Bus (not sure why I though that). But the Evo
plugin shows that there's no need to poke evolution itself for updates, and the
main application doesn't need to query the plugin if the plugin is telling the
main application about its change in status (eg. emmitting a D-Bus signal from
the plugin that the main application would receive).

> > > - If the icon is blinking because of an error, the 500 ms blink timeout
> > (obviously).
> > 
> > That's obvious, but does it respect the GTK+ no-animation configuration option?
> 
> What this has to do with the fact that making the icon blink involves running
> code every 500 ms? By the way, it seems to me that blinking cannot be considered
> an animation. GtkStatusIcon (which also supports blinking) does not respect that
> setting either.

You're right as well. Ignore that.

(In reply to comment #11)
> So it's possible (and easy) to avoid wake-ups with the new tooltips. The fact
> that they're "cheap" updates, I'm not denying, but they're also waking up the
> process needlessly.

I'm updating it every 500 ms because the displayed time is relative. Eg: "Sent:
15 seconds ago".

> You're right, it doesn't use D-Bus (not sure why I though that). But the Evo
> plugin shows that there's no need to poke evolution itself for updates, and the
> main application doesn't need to query the plugin if the plugin is telling the
> main application about its change in status (eg. emmitting a D-Bus signal from
> the plugin that the main application would receive).

I don't poke Evo for updates. I have already mentioned that I ping it to check
whether it's running or not.

(In reply to comment #12)
> (In reply to comment #11)
> > So it's possible (and easy) to avoid wake-ups with the new tooltips. The fact
> > that they're "cheap" updates, I'm not denying, but they're also waking up the
> > process needlessly.
> 
> I'm updating it every 500 ms because the displayed time is relative. Eg: "Sent:
> 15 seconds ago".

That doesn't mean you need to update the tooltip _straight away_. You could
update it only when it's going to be shown, meaning you can remove the
continuous (and unneeded) update when the tooltip isn't being shown.

> > You're right, it doesn't use D-Bus (not sure why I though that). But the Evo
> > plugin shows that there's no need to poke evolution itself for updates, and the
> > main application doesn't need to query the plugin if the plugin is telling the
> > main application about its change in status (eg. emmitting a D-Bus signal from
> > the plugin that the main application would receive).
> 
> I don't poke Evo for updates. I have already mentioned that I ping it to check
> whether it's running or not.

You could add D-Bus to your Evo plugin, and get notified when the service
appears, so you don't need to ping it.

(In reply to comment #13)
> That doesn't mean you need to update the tooltip _straight away_. You could
> update it only when it's going to be shown, meaning you can remove the
> continuous (and unneeded) update when the tooltip isn't being shown.

It's still silly. You're asking me make the code more convoluted just to save an
infinitesimal amount of resources. I've already said above that I won't do that.
It is questionable engineering, to say the least.

And btw, it would only suppress the updates that occur before the tooltip is
shown, since there is no "unquery-tooltip" signal for suppressing the updates
that occur after the tooltip has been closed.

> You could add D-Bus to your Evo plugin, and get notified when the service
> appears, so you don't need to ping it.

I might consider that option (not to get rid of the entirely neglectible ping
penalty, but to update the UI sooner after Evo is started or exited) if it turns
out that dbus provides an easy way to embed widgets in another process. I need
it for embedding the Evolution folder list widget inside the MN props dialog.

> It's still silly. You're asking me make the code more convoluted just to save an
> infinitesimal amount of resources. [...]

It might be a "infinitesimal amount of resources" if you count only MN -- but if
you look at the big picture then MN and other apps that waste a similar amount
of resources sum up to a noticeable amount of wasted resources, which results in
a higher power consumption and thus shorter battery life on laptops.

MN does not waste resources. As I said, it makes no sense to perform an
optimization which would make the code more complex if that optimization brings
no measurable performance improvements.

(In reply to comment #16)
> MN does not waste resources.

The process get active two times a second even when there is nothing to do (no
pop-up being shown, no evolution account configured, no error blinking). That
wakes up the CPU, which has to do a bit of work -- that might not be much
resources, but it are (power) resources that get wasted. And it made four people
(two of them well known developers) argue with you here, so it seems to be
important for some people.

> As I said, it makes no sense to perform an
> optimization which would make the code more complex if that optimization brings
> no measurable performance improvements.

Performance as in "faster" is not the only thing we aim for these days (and not
what this bug is about). We aim for "better energy performance" (e.g. use less
energy)

(In reply to comment #17)
> (In reply to comment #16)
> > MN does not waste resources.
> 
> The process get active two times a second even when there is nothing to do (no
> pop-up being shown, no evolution account configured, no error blinking). That
> wakes up the CPU, which has to do a bit of work -- that might not be much
> resources, but it are (power) resources that get wasted. And it made four people
> (two of them well known developers) argue with you here, so it seems to be
> important for some people.

You don't seem to realize that regardless of whether MN is blocking in poll() or
running, your CPU does not sleep. The OS has to service interrupts, schedule all
processes that are in run state (MN hardly being the only one), and so on.

> > As I said, it makes no sense to perform an
> > optimization which would make the code more complex if that optimization brings
> > no measurable performance improvements.
> 
> Performance as in "faster" is not the only thing we aim for these days (and not
> what this bug is about). We aim for "better energy performance" (e.g. use less
> energy)

These neglectible cycles consume a neglectible amount of energy.

> ...your CPU does not sleep. The OS has to service interrupts,
> schedule all processes that are in run state

But the latest Linux kernels are "tickless". In other words, no more HZ ...

It could provide a possibility where your CPU can be stopped at all until you
press some button on your laptop. The stopped (or decreased speed) CPU eats less
buttery power. Thus the idea to avoid even 0.5 sec timeouts is not soo idiotic ;)

Certainly it is some newest feature of the Linux kernels only, hence you have a
right to not handle it in the upstream project. But could you at least point for
the people where they could start to implement some patch on your code?

(In reply to comment #19)
> > ...your CPU does not sleep. The OS has to service interrupts,
> > schedule all processes that are in run state
> 
> But the latest Linux kernels are "tickless". In other words, no more HZ ...
> 
> It could provide a possibility where your CPU can be stopped at all until you
> press some button on your laptop. The stopped (or decreased speed) CPU eats less
> buttery power. Thus the idea to avoid even 0.5 sec timeouts is not soo idiotic ;)

How much power are you talking about? How much battery time do you intend to
save by complicating MN? It makes no sense to optimize if you don't know what
kind of gain can be expected from the optimization.

How much I've understood, they want to fix each of such an application, and "in
a sum" it will give an effect, just totally.

See coment #15 and how many dependencies are present for "collect" bug #204948 ...

(In reply to comment #20)
<snip>
> How much power are you talking about? How much battery time do you intend to
> save by complicating MN? It makes no sense to optimize if you don't know what
> kind of gain can be expected from the optimization.

You could save about an hour's worth of battery on a typical 4-hour battery-life
laptop, if all the applications are fixed. You can test this out easily using
powertop to disable/remove all the components that cause wakeups.

I don't doubt that you can save substantial battery time by disabling software.
You'll save even more by uninstalling your OS altogether. Yet, in a realistic
setup, the change we are discussing would have no measurable effect.

Indeed, MN is not the only cause of wakeups; even if you "fix" applications,
there will still be necessary wakeups; it's not like without MN, your CPU would
be able to idle for long.

Upstream is not considering it as a bug. Closed. :-|

it's not like without MN, your CPU would
be able to idle for long.


this is a bogus argument; it's very possible (read: I have that on my machine 
at work) to 1.4 seconds of average idle time between wakeups.

(In reply to comment #25)
> it's not like without MN, your CPU would
> be able to idle for long.
> 
> 
> this is a bogus argument; it's very possible (read: I have that on my machine 
> at work) to 1.4 seconds of average idle time between wakeups.

Yes, it's possible to disable everything and display an impressive idleness. No
cursor blinking, no applets, no web browser, no music player, and so on. I don't
deny that it's possible. You could even rewrite powertop as a standalone
bootable program and display an even more impressive idleness.

(In reply to comment #26)
> Yes, it's possible to disable everything and display an impressive idleness.
> [...]

Okay okay, this is getting out of hand. It's not black (no MN) and white (MN
running), there are more states in between. So let's try to explain it in a
different way.

Jean-Yves, MN for us is like a small electric light somewhere in a car. If it's
on then it consumes a bit of energy, which results in a bit more fuel being
consumed my the engine. That's fine for example when the light serves a purpose
 -- e.g. to find switch in the night (in the MN case: check servers, show a
pop-up if new mail arrived, do all the other things MN was designed for). But
during days, where cars are driven most of the time, having the light on is just
wasting energy. Just a bit, but there are 100 other similar lights that do it as
well, which sums up to something measurable in total. That why we try to get all
of them out if there is no reasons for them.

For MN the lights afaics can be turned of when there is no evolution running, no
pop-up being shown and no mailbox polling needed. For a lot of use cases that's
the state in which mn is most of the time (for me it definitely is). That why we
like to see MN sleeping properly when there is nothing to do. 

I assert that this optimization would have no noticeable impact. Unless proven
otherwise, I won't perform it.

"I assert that this optimization would have no noticeable impact."

Jean-Yves, are you asserting that your software is a special case, and should
not be held to the same requirement as other software? Otherwise, your argument
is senseless. If every program wakes up once per second because it has "no
noticeable impact" then the total impact can be several watts of wasted power
and thus is quite noticeable.

If you believe your program is a special case you should explain why, giving
examples that show why it's more important to wake up once per second to check
that there's no mail, rather than to wake up once per second to update a clock
that only shows minutes, or once per second to check that the mouse hasn't been
moved, or that the wireless network still has its radio switched off.

These types of wakeups have been eliminated, after considerable work, by other
people, so why does your software get to continue wasting power ?

For comment #29:

Since he is not in Cc: list, he does not hear you...

Does your comment regard to the latest upstream version 5.3? Perhaps it is
already fixed in 5.3 ...