Re: Where are the pixels ?

["John Cupitt" <jcupitt gmail com>]

On 8/7/06, Christophe Dehais <christophe dehais gmail com> 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