Re: Scrolling performance

["Clemens Eisserer" <linuxhippy gmail com>]

Hi again,

Thanks a lot for all the hints about gdk, I know found the
source-parts which I looked for and thanks to the paper I even
understand what they are doing :-)

I thought about some techniques about implementing buffer release
heuristics, however they destroy the benefit to smoe degree and have
some overhead too.
However I realized that the memory-consumption scenario is not _such_
a big problem.
If you only hold the backbuffer only as long as the window is visible
and release it the whole situation is much better because more than
2-3 open full-screen windows are unlikely and 16mb VRAM are ... well
... much more than default.
I guess parsing an enviroment-variable or such to enable/disable the
caching behaviour wouldn't be a bad idea?

lg Clemens

2006/6/26, 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