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@xxxxxxxxx>: > On 6/25/06, Clemens Eisserer <linuxhippy@xxxxxxxxx> 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 > _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
