Re: Strange behaviour of scrollbars in GTK 2.0

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

Hi Owen,

and thanks for the remarks. I think I will report this to 
bugzilla.gnome.org, altough I don't know if it is really the right place
for it.

I stupidly missed to mention the most important point concerning the 
system configuration:

The two machines described are only runnning X, the GTK applications 
themselves (and even the window manager) run on a different machine with 
two 1500Mhz Athlons and 2GB memory. The application clients are connected 
to it via 10Mbit or DSL.

Since the problems occur on both machines I don't think them to be latency 
or round trip related.

I'm not sure how, but there seem to be more events missing apart from the 
mouse events. In my application I wanted to replace the standard mechanism
of having a drawing area automatically scrolled in a scrolled window /
viewport with a drawing area of exactly the size of its visible area and
providing it with two scrollbars. If one moves the scrollbar the image is
scrolled in memory and then drawn to the widget.

Now it is possible to move the scrollbar handle back and forth at a 
certain speed (rather gentle, but over quite a range, as if spreading 
paint on a wall with a brush) so that nothing happens within the drawing
area. This is due to the fact that the application recognizes the
value-changed event of the scrollbar and calls gdk_window_invalidate_rect,
but there is no corresponding expose-event. This effect is completely
independent of the update policy of the scrollbars.

And what's even worse, just by scrolling in the way described above, X can 
suddenly consume up to 99% CPU usage. The slower a machine the heavier 
this effect.

So, even though gtk-devel-list might by the wrong place for my question, I 
regarded it at least as having some importance for matters discussed here.

Sebastian Eken
eken bfw-online de


Btw.: Although, I know, GTK_UPDATE_DISCONTINUOUS doesn't make sense for 
the problem shown right here and the one in my original posting (movement 
correctly stops after button release), I found out that it still has the
inclination to abruptly jump into different positions or even stop moving
at all, if I keep moving the mouse up and down.


On Thu, 20 Jun 2002, Owen Taylor wrote:

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