Strange behaviour of scrollbars in GTK 2.0

["S. Eken" <eken bfw-online de>]

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.

(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.

GTK version: 2.0.5 (but earlier 2.0.x releases seem to have the same
problem)

It is also very interesting that the X server consumed almost 100% of the
CPU time on the slower system and still 10% on the faster one, which
appears to be quite a lot for just redrawing the scrollbar.

I'm not sure if this topic has been discussed somewhere else before.
If so, it would be nice to let me know where.

Sebastian Eken
eken bfw-online de