Re: Scrolling performance

["John Cupitt" <jcupitt gmail com>]

On 6/25/06, Clemens Eisserer <linuxhippy gmail com> wrote:
> When I maximize the window and resize the panes I get very slow
> resizing, however when setting all involved widgets unbuffered
> resizing is fast (but painting is done with artifacts).

I think the artifacts are because, with double-buffering turned off,
expose events do not get an automatic clear-to-background. There's a
note about this in the entry for gtk_widget_set_double_buffered():

 http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html#id4004696

I'm not a gtk-internals expert and I can't really see a good solution
to this. The possibilities I can see are:

1) Provide an option to disable double buffering for all widgets

You could hack into gdk_window_begin_paint_region() and add a new code path:

 http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#id3232356

something like

 if (global_no_double_buffer)
   clear expose area to background

might be enough.

Repainting would be fast but flickery and incredibly ugly. People with
older machines and nvidia hardware acceleration would see an FPS
improvement, but their eyes would be watering.

2) Use nvidia's pixmap placement hint

I think this would require a new driver from nvidia and changes to the
X server to make the option accessible. Not going to happen any time
soon.

3) Persuade nvidia to change their pixmap caching policy

It seems to me that their policy is broken. If an app creates a
pixmap, you'd expect it to be used soon. Making new pixmaps default to
slow memory is rather odd.

But I guess they've done a lot of profiling (of non-GTK apps, heh) and
like it the way it is.

4) Have a single expose pixmap

You could allocate a single large expose pixmap (maybe as big as the
enclosing window?) and reuse that, with clipping, rather than creating
and destroying a new pixmap each time.

gdk_window_begin_paint_region() actually maintains a stack of pending
pixmaps, though I've no idea how often the stack feature is used.
Perhaps you could get away with having a single permanent expose
pixmap, and dynamically create and destroy sub-pixmaps if the stack
starts working. If the stack is used infrequently maybe this would
work OK.

This would chew up graphics card memory :-( and main memory for
software drivers :-( and small-footprint people would hate it. My
machine has 10 virtual desktops, each is 1920x1200 (so about 10MB), if
each screen is 50% covered in gtk2 apps, this change will make my X
server need an extra 50MB of RAM. Ouch!

Maybe there could be a timeout to free the backing pixmap if it's not
used for a couple of seconds.

John