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...

(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.

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.

(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 ...

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.

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?

(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).

(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.

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).

(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...

(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.

(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.

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*.

(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

(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?

(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.

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?

> (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

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.

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.

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?

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().

Created attachment 184374 [details] [review]
Fix nvidia slow, but saner

Created attachment 184375 [details] [review]
Fix nvidia slow, but saner

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.

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.

If you revert these patches do you still get the issue?

This patch shouldn't affect anything like that... mm

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.

That sounds like bug 646184, which hopefully should be unrelated to this patch.

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

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

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.

i applied both patches, from comment 23 and comment 24

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.

@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

*** Bug 647353 has been marked as a duplicate of this bug. ***

Further testing this patches, the mouse events can be lost only by switching to new workspace and come back to the old one.

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).

Yes, confirm that.