Narrow side-panels with the "window list" contents produce extremely high CPU use and hangs all panel operations.
Steps to Reproduce:
1. Create a new panel on the side.
2. Add to the panel the "Window List" option (normally defaults to the bottom panel).
3. CPU use spikes and remains high; Panel operations do not respond.
Panel operations (properties, relocate, add/delete options, etc. are unresponsive), gnome-panel consumes much of the CPU.
When the panel is displayed on the bottom panel bar, normally 15-20 characters of the window titles are displayed, the default width of side panels may be much smaller than the default width for the bottom panel bar. Adding the window list seems to work ok if one changes the preferences to a much wider side panel before adding the Window List but there are significant problems with a narrow window list. It looks like gnome-panel is getting hung up (looping) on deciding how large the individual window frames should be.
Due to the "wide screen" trend in monitors, there is much more space available on the sides of the screens than the top and bottom (esp. if one wants to read actual text pages of documents). So there will be a desire to relocate the top & bottom panel bars to the sides of the screen. It looks like this has not been tested fully for extreme cases (e.g. when the panel width is narrow (can only display a few characters of the window title) or even too narrow (not even wide enough to display the mini-icon), or cases where the number of windows exceeds the virtical display space available (in which case one is going to need some kind of scrolling option).
This is a relatively major problem as it tends to require rebooting the gnome session and some hand editing of the .gconf files (to remove the Window List option from the most recent panel) in order to return gnome to a "usable" state.
One can kill the gnome-panel and that will give one a few minutes of normal desktop use but because the gnome session restarts gnome-panel, the only way to to work around the problem is to entirely remove gnome-panel from /usr/bin (at least until one hacks the configuration back to a functional state).
Created attachment 222323 [details]
Gdb trace of CPU looping gnome-panel
Attached is a gdb trace of gnome-panel taken when it is looping and unresponsive. It looks like it has gotten into some kind of a bind if one looks at the number of active "*_size_allocate" calls which are present (and the depth of the stack).
A typical gnome-panel stack has a depth of 7 and it is waiting on a g_poll() call.
Please provide "emerge --info" output. Also check if the problem appears on a new created user account with "fresh" config files
Please provide that information and reopen then. Thanks
Thanks for taking the time to report this bug, however, since it has not been updated to provide the request information, we cannot help in resolving your issue.