GNOME Bugzilla – Bug 672091
smooth scrolling could do with some optimizations
Last modified: 2014-05-22 02:14:40 UTC
The new smooth scrolling support in gtk 3.3.18 is nice but it could do with some optimizations, the current version just generates lot of scroll events and redraws which leads to slow scrolling...
Any concrete example ? The examples I see in gtk3-demo seem to work fine...
I don't really notice it here either but my laptop is not slow, Ryan said it's quite noticable in nautilus for him, Benjamin suggested on IRC that GTK needs to do something to reduce number of value-changed events emitted, i.e merge the events in some way
I'm not convinced. Most scrollable implementations only redraw when their x or y position actually changed; not every time the adjustment value changes.
Concrete example from me: Install F17 on an ExoPC, go into the /etc from that stock install using Nautilus. Turn on list view. Use the touchscreen to scroll. I'd classify this particular use case as "embarrassingly bad".
http://git.gnome.org/browse/gtk+/commit/?id=917ca6a802af574232f413fdf904e1633d706b52 I believe this should help here.
This also applies to Empathy, Gedit and Evince using my Logitech mouse (has free-wheel mode that can send loads of scroll events when the ratchet is disabled) Gedit: Open a large document, scroll quickly. Empathy: I'm attaching a modified hircd which echoes 100 messages for each message received. Run it, connect to localhost, join an IRC channel and type 5 long-ish lines to get 500 lines of spam messages in the channel. Now try quick scrolling. Evince: Open a large PDF and zoom all the way out. Now try quickly scrolling through the document.
Created attachment 211538 [details] A spammy IRCd (test case for Empathy)
(In reply to comment #5) > http://git.gnome.org/browse/gtk+/commit/?id=917ca6a802af574232f413fdf904e1633d706b52 > I believe this should help here. seb128: Did that help?
lets assume it did