Re: Strange behaviour of scrollbars in GTK 2.0

[Owen Taylor <otaylor redhat com>]

To my knowledge this hasn't been previously reported. The right
place to report a bug is bugzilla.gnome.org.


"S. Eken" <eken bfw-online de> writes:

> Hello,
> 
> could it be that the scrollbars in GTK 2.0 do have problems with race
> conditions while processing mouse events?
> 
> Taking a look at gtk-demo will hopefully demonstrate this:
> 
> 1. Start gtk-demo (comes with GTK and should be installed under
>    /usr/bin, /usr/local/bin or wherever GTK was installed)
> 2. Double click on "Stock item and Icon Browser"
> 3. A window containing a list view should appear
> 
> Now if you press down the left mouse button on the "handle" of the list's
> scrollbar and keep it pressed while moving the mouse up and down several
> times, you will notice that the scrollbar follows the movements of the
> mouse for a while even after you released the mouse button.
> 
> It seems that the release-event is processed after some unnecessary
> motion-events.

[ Doesn't sound like a "race condition", just like GtkRange isn't
  catching up on mouse event ]

> (btw.: sometimes the scrollbar "handle" even loses the smoothness of its
> movements, which means that it starts to jump into new positions)
> 
> We have tried this out with different systems (even with an application
> where moving the scrollbar wasn't connected to any event)
> 1. CPU: i486/66Mhz, Memory: 16MB, Network: 10Mbit (shared), Display: 8bit
> colour
>    depth, Kernel: Linux 2.0.38
> 2. CPU: AMD K6/300Mhz, Memory: 96MB, Network: 768kBit DSL, Display: 8bit
> colour
>    depth, Kernel: Linux 2.2.17pre6,
> but the result was the same.

The first machine, I'm afraid, is beneath what I'd consider the minimum
requirements for GTK+-2.0. The machine that I was using when working
on GTK+-1.0 five years ago had twice the memory and processor, and
wasn't at all high-end... 

The second machine is more reasonable ... there are some
other known problem with using GTK+ over high latency, see:

 http://bugzilla.gnome.org/show_bug.cgi?id=70236

(I'm not saying that GtkRange shouldn't catch up on motion events, just
that in both cases I wouldn't expect GTK+ to feel snappy.)

Regards,
                                        Owen