Re: Strange behaviour of scrollbars in GTK 2.0

[Owen Taylor <otaylor redhat com>]

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

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

If you just keep and processing mouse events and they take longer to
process than it does for the next one to come in, then redrawing
won't happen.

That's one reason, if you look at the sources to GtkViewport,
GtkTextView, etc, you'll see that they call
gdk_window_process_updates() after scrolling.

Generally, the best thing to do when handling mouse events is to try
make handling them really cheap, then handle the hard work in an "idle
function". It may be that some work can to done to make GtkScrollbar
a bit cheaper.

Regards,
                                        Owen