F13 - Some gtk+ function seem very slow

[xolotl]

Hello - Yesterday I installed F13 onto a somewhat older machine of mine, to test out some software that I've been developing, and while it works quite well in general, there's a couple of situations where gtk+ seems to be incredibly slow.

Most notably, that app lets the user click-and-drag a large map inside a scrolled window; the app updates the scrollbars appropriately. On F13, the click-and-drag starts to lag behind the mouse almost immediately. I had been developing this app on another distro (Gentoo) prior to installing F13 on the machine, and never had this issue then - I've even doublechecked by booting that box onto a Gentoo LiveCD and trying from there, and the speed of click-and-drag is totally fine.

Additionally, and possibly-related: the highlighting which follows the mouse around as you mouseover the map seems to lag behind as well. Otherwise, the system responds quite quickly.

Now, the box is an Athlon XP 2100+ (1.73GHz) with an nVidia 7600GS (AGP) - I've tried using all three of nv, nouveau, and the binary nVidia drivers (both from rpmfusion, and compiled from nvidia.com), and I get the same lag using any of those X drivers.

I've tried changing the desktop theme (in Preferences->Appearance) to some more "basic" themes, but that hasn't affected anything... I've also tried hopping into a very basic WM outside of Gnome (icewm) but the problem persists there. I can't shake the feeling that this is some gtk+ setting getting in the way...

... is there some kind of global "smooth scrolling" gtk+ option I could turn off somewhere, perhaps? Anyone have any ideas? Run into this kind of weird, selective gtk+ slowness before?

---------- Post added at 12:02 PM CDT ---------- Previous post was at 11:44 AM CDT ----------

Oh, and I hadn't thought to try before, but I've just verified that I get the same behavior with the "vesa" driver. The system is otherwise snappy, but that click-and-drag is still horribly slow.

---------- Post added at 12:44 PM CDT ---------- Previous post was at 12:02 PM CDT ----------

Okay, one MORE update - just tried it out on an Ubuntu LiveCD, and the speed is also totally fine on there. Just, you know, as one more datapoint...

---------- Post added at 02:30 PM CDT ---------- Previous post was at 12:44 PM CDT ----------

Okay, so I went ahead and put together a simple test-case which is removed from the actual application, and it still exhibits the same behavior for me. On Fedora 13 it's quite laggy, on other distros on the same hardware it's totally fine. If somebody else wants to give it a go, I'd appreciate it (especially if you're on older hardware like I am)

http://apocalyptech.com/clickdrag_test.py

[Dies]

Your results are not that surprising, at least not to me.

Personally, if it works well on almost every other distro and Fedora is not the main target for it, I would just blow Fedora users off.

Yeah, I know, that's kind of rude and Fedora is a major player, but then again if it works well everywhere else then it's obviously not a problem on your end and wasting your time trying to work around it is not a good idea especially considering the pace of Fedora development.

Have you tried it in F12?

[pankajp]

It is an interesting post imo. (Sorry i cant help you here)
I noticed that you are testing on live-cds of other distros, can you also test it on live fedora.

Your code actually runs perfectly on my F13 (no lag in drawing on dragging) but i'm on intel graphics w/o any graphics card so may not be relevant to you.

As Dies said if it works on every other distro then you could just move on to some other, but it'd be better if you could file a bug report.

[xolotl]

Yeah, I was actually pretty close to abandoning the issue, after having gone through and changed every BIOS option on the AGP bus that I could, when suddenly the nouveau driver (so long as I was using a kernel either from the *-testing repos, or a kernel direct from nouveau's git) started working without lag, so long as I was passing "nouveau.noagp=1" to the kernel boot line.

Which is especially bizarre given that it started working once I had given up and just reverted all my changes to the way things were when I started running through combinations. Rather odd; I assume that there's got to be some measure of user error here. Probably I touched something inadvertantly which I didn't realize, which is now causing it to work fine.

The updates are still slow using vesa; I haven't wanted to rock the boat by trying nv, or re-doing the updates to try the binary nVidia drivers. I've had reports from other F13 users that it runs fine for them anyway, so I'm just gonna chalk this one up to some weird hardware combination on my end.

Anyway, thanks for the responses! Wish I had something more definite to report in the way of solution.