After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630533 - Massive slowdown caused by moving icons to the message tray
Massive slowdown caused by moving icons to the message tray
Status: RESOLVED NOTGNOME
Product: gnome-shell
Classification: Core
Component: message-tray
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 647353 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-09-24 16:39 UTC by drago01
Modified: 2011-04-12 08:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nvidia: Hack for fast message tray (6.19 KB, patch)
2011-03-27 05:47 UTC, Jasper St. Pierre (not reading bugmail)
rejected Details | Review
Fix nvidia slow, but saner (3.94 KB, patch)
2011-03-27 18:01 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
Fix nvidia slow, but saner (2.42 KB, patch)
2011-03-27 18:01 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review

Description drago01 2010-09-24 16:39:14 UTC
Commit cbf2cbac610fa771fd7efcc47c96fd1f8280a9fa moved the non system icons to the message tray which results into a huge slowdown when an icon is actually in the tray.

Numbers:
Icon in tray:
overviewFpsFirst 9.3753222767, 9.16838191812, 9.12791865199 

Wthout icon in the tray:
overviewFpsSubsequent 32.3455947097, 32.3481523814, 32.1683620585

This is a rather huge hit for just moving stuff around ...
Comment 1 Dan Winship 2010-09-24 19:32:13 UTC
what icons do you have in your tray?

if one of them was constantly redrawing itself, then presumably it would take more time to redraw itself over the message tray's gradient background than it would over the solid panel background...
Comment 2 drago01 2010-09-24 19:50:08 UTC
(In reply to comment #1)
> what icons do you have in your tray?

Pidgin

> if one of them was constantly redrawing itself, then presumably it would take
> more time to redraw itself over the message tray's gradient background than it
> would over the solid panel background...

It does not visible redraw itself.
Comment 3 Jonathan Strander 2010-09-28 14:55:28 UTC
I'll confirm this. It works with the empathy icon, pidgin, deluge, rhythmbox, update-notifier, and any other icon I can throw at it. They all cause the extreme performance dip.
Comment 4 drago01 2010-10-02 19:40:36 UTC
(In reply to comment #1)
> what icons do you have in your tray?
> 
> if one of them was constantly redrawing itself, then presumably it would take
> more time to redraw itself over the message tray's gradient background than it
> would over the solid panel background...

Using a solid background does not change anything, while debugging the only 2 ways I found to get rid of the slowness was either not showing the messagetray at all or not showing the icon at all ... 

I was removing as much as possible from the tray to avoid any sequence that might cause it but none makes any difference.

Keeping it reverted locally is not a solution either as every update becomes painful to rebase ...
Comment 5 drago01 2010-10-02 19:54:42 UTC
OK as the only real difference between the icons on top and the ones in the message tray is the animation I tried two things:

a) Never hide the summary
and
b) Do not tween in _showSummary

Both a) and b) do fix the slowdown.
Comment 6 Dan Winship 2010-10-03 01:02:02 UTC
so the additonal slowness is only when it's actually animating the summary? or does animating the summary once somehow cause it to always be slow after that?
Comment 7 drago01 2010-10-03 07:59:49 UTC
(In reply to comment #6)
> so the additonal slowness is only when it's actually animating the summary? or
> does animating the summary once somehow cause it to always be slow after that?

It seems to be slow while animating it (as we animate it while entering the overview, the slowdown is catched by perf).
Comment 8 drago01 2010-10-03 09:08:26 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > so the additonal slowness is only when it's actually animating the summary? or
> > does animating the summary once somehow cause it to always be slow after that?
> 
> It seems to be slow while animating it (as we animate it while entering the
> overview, the slowdown is catched by perf).

OK, now I got the cause.

We do set automatic = TRUE for the TFP texture, which seems to result into us rebinding the texture as if there is no tomorrow (and thus causing the slowdown). 

When automatic is set to TRUE the texture is only rebind when it is damaged (i.e receives a damage event due to the app drawing).

The only problem with setting it to automatic is that the icons end up surrounded by a black rectangle.

But ...

We actually set automatic to TRUE in shell_gtk_embed_init and then use FALSE when setting the window.

The comments here confuse me though as shell_gtk_embed_init it says:

  /* automatic here means whether ClutterX11TexturePixmap should
   * process damage update and refresh the pixmap itself.
   */

Which makes sense and agrees with the docs, but in shell_gtk_embed_on_window_realize it says 

  /* Here automatic=FALSE means to use CompositeRedirectManual.
   * That is, the X server shouldn't draw the window onto the
   * screen.
   */

Which by looking at the clutter code seems to be correct either (automatic here means CompositeRedirectManual vs. CompositeRedirectAutomatic). 

So I am still not sure what the problem is exactly.
Comment 9 drago01 2010-10-03 09:21:00 UTC
My other theory:

If mutter is already creating a TFP texture for the tray window and we do it again, we end up hitting the software fallback (hence while rebinding hurts that much).
Comment 10 Dan Winship 2010-10-03 13:46:32 UTC
(In reply to comment #8)
> The comments here confuse me

The 'automatic' parameter to clutter_x11_texture_pixmap_set_automatic() and the 'automatic' parameter to clutter_x11_texture_pixmap_set_window() are entirely separate things. (The former sets texture->priv->automatic_updates and the latter sets texture->priv->window_redirect_automatic.) The comments were supposed to be disambiguating that fact...
Comment 11 drago01 2010-10-03 16:04:30 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > The comments here confuse me
> 
> The 'automatic' parameter to clutter_x11_texture_pixmap_set_automatic() and the
> 'automatic' parameter to clutter_x11_texture_pixmap_set_window() are entirely
> separate things. (The former sets texture->priv->automatic_updates and the
> latter sets texture->priv->window_redirect_automatic.) The comments were
> supposed to be disambiguating that fact...

Yeah I got that after reading the clutter code.
Comment 12 drago01 2010-10-04 17:42:40 UTC
(In reply to comment #9)
> My other theory:
> 
> If mutter is already creating a TFP texture for the tray window and we do it
> again, we end up hitting the software fallback (hence while rebinding hurts
> that much).

FWIW, I just confirmed that this theory is wrong, we don't do that and thus do not hit that code path.
Comment 13 Owen Taylor 2010-10-05 17:37:08 UTC
I'd appreciate if people could test the patch in:

 http://bugzilla.clutter-project.org/show_bug.cgi?id=2356

It looks to me like we were restarting from scratch with the tray icons and doing several X server round trips every time we got a ConfigureEvent that indicated a *move*.
Comment 14 drago01 2010-10-05 17:51:14 UTC
(In reply to comment #13)
> I'd appreciate if people could test the patch in:
> 
>  http://bugzilla.clutter-project.org/show_bug.cgi?id=2356
> 
> It looks to me like we were restarting from scratch with the tray icons and
> doing several X server round trips every time we got a ConfigureEvent that
> indicated a *move*.

Hmm does not seem to fix it.

With patch applied:

Icon in tray:

# Frames rate when going to the overview, second time
overviewFpsSubsequent 13.0671809909, 13.0564666068, 13.1128624067

No icon in tray:

# Frames rate when going to the overview, second time
overviewFpsSubsequent 36.2148263499, 35.5966895079, 35.3795697137
Comment 15 Owen Taylor 2010-10-05 17:55:56 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > I'd appreciate if people could test the patch in:
> > 
> >  http://bugzilla.clutter-project.org/show_bug.cgi?id=2356
> > 
> > It looks to me like we were restarting from scratch with the tray icons and
> > doing several X server round trips every time we got a ConfigureEvent that
> > indicated a *move*.
> 
> Hmm does not seem to fix it.
> 
> With patch applied:
> 
> Icon in tray:
> 
> # Frames rate when going to the overview, second time
> overviewFpsSubsequent 13.0671809909, 13.0564666068, 13.1128624067
> 
> No icon in tray:
> 
> # Frames rate when going to the overview, second time
> overviewFpsSubsequent 36.2148263499, 35.5966895079, 35.3795697137

- Does the patch make a difference at all?
- If you:
   - Run mutter under gdb from a different computer
   - St.set_slow_down_factor(50) in Lg
   - Start going to the overview
   - Control-c to break in gdb
   - (gdb) break clutter_x11_texture_pixmap_set_pixmap
   - (gdb) continue
  Is that breakpoint hit?
Comment 16 drago01 2010-10-05 20:39:35 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > I'd appreciate if people could test the patch in:
> > > 
> > >  http://bugzilla.clutter-project.org/show_bug.cgi?id=2356
> > > 
> > > It looks to me like we were restarting from scratch with the tray icons and
> > > doing several X server round trips every time we got a ConfigureEvent that
> > > indicated a *move*.
> > 
> > Hmm does not seem to fix it.
> > 
> > With patch applied:
> > 
> > Icon in tray:
> > 
> > # Frames rate when going to the overview, second time
> > overviewFpsSubsequent 13.0671809909, 13.0564666068, 13.1128624067
> > 
> > No icon in tray:
> > 
> > # Frames rate when going to the overview, second time
> > overviewFpsSubsequent 36.2148263499, 35.5966895079, 35.3795697137
> 
> - Does the patch make a difference at all?
> - If you:
>    - Run mutter under gdb from a different computer
>    - St.set_slow_down_factor(50) in Lg
>    - Start going to the overview
>    - Control-c to break in gdb
>    - (gdb) break clutter_x11_texture_pixmap_set_pixmap
>    - (gdb) continue
>   Is that breakpoint hit?

No it isn't, sync_window_internal is only hit twice and does not seem to hit that need to set the pixmap.
Comment 17 drago01 2010-10-09 21:09:02 UTC
OK, got some more time and did some testing it seems only reproduceable on nvidia hardware, on intel the tray icon only causes a 2-3 fps drop compared to the 2/3 on nvidia.

(In reply to comment #3)
> I'll confirm this. It works with the empathy icon, pidgin, deluge, rhythmbox,
> update-notifier, and any other icon I can throw at it. They all cause the
> extreme performance dip.

Are you using nvidia?
Comment 18 Jonathan Strander 2010-10-10 00:00:06 UTC
> (In reply to comment #3)
> > I'll confirm this. It works with the empathy icon, pidgin, deluge, rhythmbox,
> > update-notifier, and any other icon I can throw at it. They all cause the
> > extreme performance dip.
> 
> Are you using nvidia?

Correct. Specifically GTX 460 w/ 256.53 driver
Comment 19 Jasper St. Pierre (not reading bugmail) 2011-03-27 05:47:51 UTC
Created attachment 184339 [details] [review]
nvidia: Hack for fast message tray

This is not kosher at all, and doesn't work 100%. Just an insane hack so I can
have not slow.
Comment 20 drago01 2011-03-27 08:25:43 UTC
This comment got eaten by the database failure (adding outcome of the IRC conversation for the record):

--- Comment #19 from Dan Winship <danw@gnome.org> 2011-03-24 16:45:11 UTC ---
> At some point it was determined that the problem is that moving the X Windows
> associated with the trayicons is incredibly slow on nvidia for some reason.

> The one thing that is very weird about our trayicon handling is that the
> trayicons are reparented into the stage window, which is itself a child of the
> Composite Overlay Window. It's possible that the nvidia driver doesn't deal
> well with that scenario.

> Given that we now have event forwarding for trayicons, we might be able to get
> them out of the stage... The first thing to try would be to put them in the COW
> directly, as siblings of the stage, but stacked underneath it.

That doesn't work.

>  That might let
> the nvidia driver realize it can ignore their motion, since they'd be obscured.
> If that didn't work, another possibility would be to make them normal windows
> (ie, children of the root window), but that will cause other problems since
> they'd start showing up in the window list, etc. (Or does mutter ignore its own
> X windows? I guess that would make sense...)

That does but mutter does not ignore thus windows.
Comment 21 Jasper St. Pierre (not reading bugmail) 2011-03-27 09:06:19 UTC
Hmm... could we just create a window, stick it in hidden_group, and then reparent the xembed children to that instead of to the stage?
Comment 22 Dan Winship 2011-03-27 13:20:45 UTC
hidden_group is a ClutterActor. Everything Clutter-related is inside the stage X Window.

You need to create a new X Window, reparent the xembed children into that, and add that window to the blacklist near the start of meta_window_new_with_attrs().
Comment 23 Jasper St. Pierre (not reading bugmail) 2011-03-27 18:01:25 UTC
Created attachment 184374 [details] [review]
Fix nvidia slow, but saner
Comment 24 Jasper St. Pierre (not reading bugmail) 2011-03-27 18:01:34 UTC
Created attachment 184375 [details] [review]
Fix nvidia slow, but saner
Comment 25 Jasper St. Pierre (not reading bugmail) 2011-03-27 18:02:46 UTC
I know these are terrible commit messages. The former patch is for mutter, the latter is for gnome-shell.

Marking the first one as rejected.
Comment 26 David Sepashvili 2011-04-04 23:07:21 UTC
I tried this patches, they fixed this issue but causes new one, after restart gnome-shell, and playing around, my mouse both buttons loses effect. I could move cursor and that's all, i moved it to the right top corner and start new program, everything back to normal; few times ago it's repeat, and so on.
Comment 27 Jonathan Strander 2011-04-04 23:14:56 UTC
If you revert these patches do you still get the issue?

This patch shouldn't affect anything like that... mm
Comment 28 David Sepashvili 2011-04-04 23:49:41 UTC
Step by step what i have done:

1)Revert patches - Recompile - Reinstall mutter and gnome-shell
2)Restart Xorg server.
3)After everything start, I pushed Alt-f2 and write there empathy.
4)Everything works, except "Massive slowdown".

5) Get patches back - Recompile- Reinstall mutter and gnome-shell
7) Restart Xorg server.
8) After everything start, I pushed Alt-f2 and write there empathy.
9) After empathy starts bushed to the |X| to close window.
10) Pushed Alt-Tab.
Result: 
* Empathy shows up, but mouse buttons died, like i described below.
* If I will move mouse to the top-left corner, empathy window doesn't exists there at all. It's just disappears there. 
* If I will go back to the workspace (top-left-corner once agian) Empathy window shows up again and mouse buttons are dead.
* If I will run another application there are chances that i will back my mouse buttons work.
* If I get my mouse buttons and close empathy tray icon doesn't work any more, I can't call empathy by clicking on the tray icon only Alt-tab.

Fell free to ask any more information you will need, and hope this will help.
Comment 29 Jasper St. Pierre (not reading bugmail) 2011-04-05 00:10:55 UTC
That sounds like bug 646184, which hopefully should be unrelated to this patch.
Comment 30 Ionut Biru 2011-04-09 23:54:34 UTC
i have the same problem as David after applying this patches. Sometimes i lose mouse events for clicks and i have to restart the shell. alt+f2, r. Is not related to empathy, i cannot click even in gnome-termina, firefox, favorites

this didn't happen at all until now and i'm using the shell since 2.91.6. Something is fishy with this patches
Comment 31 Ionut Biru 2011-04-09 23:58:13 UTC
Window manager warning: Log level 16: value "-nan" of type `gfloat' is invalid or out of range for property `y' of type `gfloat'
Window manager warning: Log level 16: value "-nan" of type `gfloat' is invalid or out of range for property `y' of type `gfloat'
Window manager warning: Log level 16: value "nan" of type `gfloat' is invalid or out of range for property `y' of type `gfloat'


found this in ~/.xsession-errors but i'm not sure if is related
Comment 32 Jasper St. Pierre (not reading bugmail) 2011-04-10 04:40:48 UTC
Which patches did you apply?

There's one mutter patch, and one gnome-shell patch, both titled "Fix nvidia slow, but saner". You need both. Don't apply the rejected "nvidia: Hack for fast message tray" that may have caused that NaN exception.

I'll work on the cleanup of those patches, write a proper commit message, etc. soon.
Comment 33 Ionut Biru 2011-04-10 07:05:03 UTC
i applied both patches, from comment 23 and comment 24
Comment 34 David Sepashvili 2011-04-10 07:15:59 UTC
I confirm everything Ionut saing:
    ->I had applied both patched from comment 23 and 24;
    ->sometimes I lose mouse events for clicks;
    ->it's not related to empathy.
Comment 35 Ionut Biru 2011-04-10 08:43:59 UTC
@Jasper steps to replicate

1) have several workspaces with applications running
2) move the an empty workspace.
3) start an application
4) close that application
5) move the other workspaces and notices that mouse events are lost
Comment 36 Florian Müllner 2011-04-10 12:55:12 UTC
*** Bug 647353 has been marked as a duplicate of this bug. ***
Comment 37 Ionut Biru 2011-04-10 13:04:53 UTC
Further testing this patches, the mouse events can be lost only by switching to new workspace and come back to the old one.
Comment 38 drago01 2011-04-12 07:31:33 UTC
NVIDIA has fixed that bug in the 270.41.03 driver release (even thought the ChangeLog does not mention it), I get 60fps with icons in the tray and no flickering whatever.

Which means no need for any of the hacks being discussed here.

Can someone else please test with that driver and confirm the fix? (Will close the bug as NOTGNOME after that).
Comment 39 David Sepashvili 2011-04-12 08:11:51 UTC
Yes, confirm that.