Closed ghost closed 10 years ago
I think I've fixed it, see fa9b87f0371597b9a2fd9713930cd9530c0b2f72 if you're interested in the gory details.
I'm surprised the effects weren't more dramatic (I never noticed any lag on my system), perhaps gnome-shell masked this stupidity by dropping too many scheduled events. Anyway, thanks for pointing this out :)
Thanks, I appreciate your quick response to this issue-- I just patched the file and don't perceive any lag now when I move around windows. However, I'm always seeing at least 100% utilization of one logical core along with anywhere from 20-100% utilization of a second. Although, it doesn't really affect the perceived performance on my system, those with dual core processors with no HT would be very affected by this.
The 100% utilization is more or less expected, unfortunately - I'm basically looping until the operation is over, because there's no signal for "the user has finished" a drag, only "the user is currently dragging". Each iteration of that loop is performed only when gnome-shell is idle though, so it shouldn't interfere with regular processing, except maybe a small amount of CPU starvation of other processes. I could possibly increase the timeout between checks, but I suspect drag ops are sufficiently short and infrequent that it's not really worth it.
I'm currently using the latest version (from your GitHub) running through 0install on Fedora 20 with GNOME 3.10. When I enable extension and choose either the vertical or horizontal tiling mode, I see my CPU utilization spike when moving around the windows with the mouse. This is on a laptop with an Intel i7 3720QM using the Ivy Bridge HD4000 graphics.