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
