Re: Scrolling performance
- From: Paul Davis <paul linuxaudiosystems com>
- To: Valdis Kletnieks vt edu
- Cc: gtk-list gnome org
- Subject: Re: Scrolling performance
- Date: Tue, 20 Jun 2006 21:00:15 -0400
On Tue, 2006-06-20 at 19:43 -0400, Valdis Kletnieks vt edu wrote:
> Was this your Eclipse test, or gftp? What I'm seeing on the 'wiggle the
> dividing bar on gftp till it saturates the CPU' is this: (and yes, it's a
> generic GTK issue, not gftp, unless the 3 other apps I tested did the same
> wrong thing with it.. ;)
i talked for a little while with tim janik at LAC2006 this year about
this very issue. GTK1's pane widget used the standard draw-with-XOR to
indicate the new position of the divider, and the resize didn't occur
till mouse release. GTK2, for some unknown reason, abandoned that
approach and instead keeps issuing resize events as the mouse moves. its
completely and totally braindead as the default behaviour, although i
would concede that there are situations where it would be nice to have
this available.
in ardour, dragging panes around like this causes a more or less
complete redraw of our monster canvas widget, which causes absurdly slow
and ugly visuals while doing it. i've looked at rewriting GtkPaned to
use the old behaviour by default, but it was just too much work for me
to get into at the time i was looking into it.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]