GNOME Bugzilla – Bug 103811
Add smooth scrolling
Last modified: 2014-10-04 20:55:07 UTC
See http://mail.gnome.org/archives/gtk-devel-list/2003-January/msg00083.html
Created attachment 17889 [details] [review] Updated patch -- this one also only redraws Ranges when their layouts actually change
Along with smooth scrolling, "exponential acceleration" would be great. I think I had seen this behaviour in konqueror, where scrolling speed would raise progressively while keeping an arrow key pressed for instance.
*** Bug 148366 has been marked as a duplicate of this bug. ***
Created attachment 29863 [details] [review] New patch that applies to 2.4 People occasionally mail me and ask about an new version that applies to 2.4, so here it is.
By the way, one improvement (which isn't included in this patch) would be to add a gdk_graphics_flush() that would call XGetImage() to make sure the graphics pipeline is actually finished. (Even better of course would be to get proper support for that operation in X).
XGetImage() style flushing is really not what you want since that actually stalls the graphics pipeline until its empty as I understand how the X server works (though the X protocol may not require that)... you really just want breadcrumbs... "have all requests from this client been executed" It's not clear to me that graphics pipelines are actually deep enough in practice that worrying about when stuff actually gets to the screen matters.
I actually implemented XGetImage() style flushing (but it's currently tangled up with a ton of other changes), and I think it did improve the scrolling, but that could just be placebo. I agree it's bad that XGetImage() flushes the graphics pipeline, but in practice that might not matter too much, since there is probably just one active application and that application is going to wait for the result of XGetImage() anyway before sending more requests. But yes, breadcrumbs are clearly better.
This is Debian bug <http://bugs.debian.org/184850>.
Created attachment 33953 [details] spintest.c Test program exposing a bug in the proposed patch. value-changed signal gets emitted twice, whereas in unpatched gtk+ it's only emitted once.
Created attachment 33954 [details] [review] a new fixed patch This fixes the problem of comment #9. It is against gtk+-2.4.13.
Does anyone know if there's a version of this patch that applies to gtk 2.6? I know it's just out but I thought you might have been tracking 2.5.x.
Gtk 2.6 has been released. Could someone fix the patch PLEASE?
This is an experimental patch, if it was a finished, accepted thing it would be in GTK+. If you don't have the technical knowledge to port it to GTK+-2.6 ourself, you probably shouldn't be running it...
Rather stop using Gnome.. Not having smooth scrolling is deadly for usability.
Created attachment 38308 [details] [review] Smoothscroll for GTK+ 2.6 (from gentoo) Gentoo's got a patch for 2.6. How come this wasn't sent upstream? Include?
The Gentoo people really need a big LART. Not only was this patch not considered ready to go into GTK+, it changes the GTK+ public API...
<foser> ernstp: i'm not happy you added my patch without my consent.. i made it buildable, i still consider it halfbroken <foser> it is open.. but i'm not pushing it for inclusion as long as i'm not content with it, thats the difference tberman I thought it should be avaliable to others to try out and improve.
qt has smooth scrolling
Just wanted to say I've been using Gentoo with this patch for a year or more, and it's been working very well. Have not tried it on a really slow machine, though (the slowest is a P4 @ 2.2 GHz with a GEFORCE 2 video subsystem). Gentoo recently backed out the patch, and when I first started to use Gnome after updating it I thought I'd gone crosseyed! Fortunately Gentoo makes it reasonably convenient to reinsert the patch (using "portage overlays"). The smoothscroll capability (even if not this specific patch) really should be in gtk, IMHO.
It will be good if we will create experimental smooth scroll in head
*** Bug 345435 has been marked as a duplicate of this bug. ***
Created attachment 107978 [details] [review] Smoothscroll for 2.13.1 I have updated Søren's patch for GTK 2.13.1. It still works great and I hope this feature can be added to GTK soon. In this patch I have used g_timeout_add_full to restrict the redraws to 50 fps instead of the original g_idle_add_full. It seems to work just as well and is much less taxing on the cpu.
Created attachment 108030 [details] [review] Smoothscroll for 2.13.1 patch #2 Updated patch which fixes some issues with the last one. gtk_widget_queue_draw () is called in the right place in gtk_range_adjustment_changed (). The changes to GdkWindow is undone, they seem to make no visible difference (on my machine).
Created attachment 108137 [details] [review] Third update, two dead functions removed
I'd love to see this patch applied once and for all, can someone in the know explain what's blocking it? Is there anything a user (v. limited programming experience - sorry) can do to help with this? Thanks
I want to ask why this patch is still not in the codebase? What problems with it? What should be improved?
Same question.
Yes, an update would be nice. Does this patch still apply well on the latest GTK 2 or even GTK 3? Technically, I see no reason why my phone has smooth scrolling while my PC still has not.
I also opened this bug downstream on launchpad. https://bugs.launchpad.net/ayatana-design/+bug/868510
>Does this patch still apply well on the latest GTK 2 or even GTK 3? no
Should we mark this as a dupe of bug 516725, which has updated patches for GTK3 and GTK2?
(In reply to comment #31) > Should we mark this as a dupe of bug 516725, which has updated patches for GTK3 > and GTK2? The bug 516725 is related yet not the exactly the same. It primarily focuses on devices that export extended scroll information from what I understand. Not sure if a classic wheel mouse is the type of such device, all would depend on Xorg drivers I guess. It however creates a new infrastructure and if the "legacy" devices are not supported from the beginning, it would be nice to build a kind of emulation, either in gtk or (preferably) in Xorg drivers. Worth to say, I've been using the patch from this bug for a long time on my home system and it worked just great.
It looks like some progress was made since the last comment of this report. According to Phoronix, Synaptics and evdev are now handling smooth scrolling*, and it also works with some apps in Ubuntu Precise according to the downstream Launchpad report. Is there something to fix in GTK+ to ensure full smooth scrolling support for all GTK apps ? *http://www.phoronix.com/scan.php?page=news_item&px=MTA2ODE
No
*** Bug 693617 has been marked as a duplicate of this bug. ***
I consider this done, with the fine adjustment mode and autoscrolling that we have now.