GNOME Bugzilla – Bug 634362
Window close button in overview takes seconds to appear (Intel card)
Last modified: 2010-11-24 16:52:05 UTC
The cross image that allows closing windows in the overview takes one or two seconds to appear on my machine. But this only happens when it's the first time you hover on a specific window after entering the overview. Moving the pointer back to a window you already hovered on makes the close button appear instantly; and going out and back to the overview brings back the delay. I've noticed the button image projects shadow on the window, so the problem may come from there. That's the only cause I can think of, since it seems to require computing for each separate window. This is with an Intel 915GM card, with drivers from git.
Same here with i965, might add that the close sign also has the same delay before it disappears when you move the mouse pointer away.
In some profiling that Dave Arlie was doing, it turned up that shadowing the 22x22 button image ends up doing a glGetTexImage() on the entire atlas texture, which for me is 2048x2048. On the r300g driver this ended up going through a floating point code path, but it's a pretty bad thing to do even with good code paths, and is almost certainly the problem here. Some ideas for fixing: * Fix Cogl to map the full texture as a fbo and use glReadPixels() to read the region we need from it. * When converting a GdkPixbuf to a cogl texture, keep the GdkPixbuf around and attach it to the cogl texture (unfortunately, there's no user data facility on CoglTexture/CoglHandle at the moment. Can use GDataSet, which involves a global mutex and hash table, but is vastly better than reading 16megs of data from vram to get a 22x22 image.)
As a side note, I've just understood this small bug makes it very painful to drag and drop windows, since while the close button is being "drawn", the current position of the pointer isn't taken into account. This means the window you'll end up dragging is the one that's under the pointer at the moment the drawing of the button completes - most often, you're already at the destination point, and the result is not what you intended at all.
(In reply to comment #2) > Some ideas for fixing: > > * Fix Cogl to map the full texture as a fbo and use glReadPixels() to read the > region we need from it. > * When converting a GdkPixbuf to a cogl texture, keep the GdkPixbuf around and > attach it to the cogl texture (unfortunately, there's no user data facility on > CoglTexture/CoglHandle at the moment. Can use GDataSet, which involves a global > mutex and hash table, but is vastly better than reading 16megs of data from > vram to get a 22x22 image.) Another option could be to pass COGL_TEXTURE_NO_ATLAS to cogl_texture_new() if the theme node has a shadow. Passing it unconditionally makes the close buttons appear instantly here, doing it conditionally would require quite a few modifications in StTextureCache though ...
(In reply to comment #3) > As a side note, I've just understood this small bug makes it very painful to > drag and drop windows, since while the close button is being "drawn", the > current position of the pointer isn't taken into account. > > This means the window you'll end up dragging is the one that's under the > pointer at the moment the drawing of the button completes - most often, you're > already at the destination point, and the result is not what you intended at > all. That's what I've filed as bug #633389
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414 has the fix for Cogl to use glReadPixels. While reading data back from VRAM is never a cheap operation, it seems to pretty much fully solve this bottleneck.
On my machine the clutter patch makes a pretty big difference, gnome-shell gets a lot faster for me with no visible problems. Even the overview-relayout branch is now usable. Grabbing a window immediately after dragging another one is still not possible, but the delay before being able to do this is way shorter. App highlighting in the app well is still kinda slow (guess that's related to this bug) when you move the mouse pointer over the apps. Great work!
I've pushed those into Clutter. Thanks for the great work Owen.
I confirm the fix is very good, the button appears instantly now.