On 8/7/06, Christophe Dehais <christophe.dehais@xxxxxxxxx> wrote: > What is not clear to me is whether or not a GdkWindow contains the real > pixels in some way. Let's assume this scenario: a window is created and its > size is computed through size negociation, then a pixel buffer containing > all pixels for the window is allocated. No, GTK doesn't work like this. Like X, there are no pixel buffers. Instead, applications are sent expose events and have to be able to redraw parts of their windows when asked. Of course one way they can do this is by allocating a pixel buffer themselves and copying parts of that to the screen on request, but they are free to do it some other way if they want. The purpose of a GdkWindow is to do clipping, coordinate transformation and event management. They do not hold pixels. GTK does automatic double buffering for you. So when an expose event occurs, it allocates an off screen pixel buffer as big as the damaged region and redirects drawing there. When the applications handler has finished drawing to the off screen buffer, GTK copes it to the screen and frees it. This is why you should only ever draw in expose handlers. The system works like this to reduce memory usage. X was designed in the 1980s for workstations with 4 MB of RAM ... you just couldn't afford pixel buffers for all the windows. It was much better to just ask programs to reissue the drawing commands for the damaged areas. Things are changing a bit now with the introduction of XGL and friends. There are pixel buffers for each window at some level in the system. GTK's redraw-on-expose model will stay though (I think). John _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
