Re: the right way to draw in a drawingarea

[Paul Davis <paul linuxaudiosystems com>]

On Wed, 2005-10-12 at 08:15 -0500, the two Paul Davises wrote to each
other:
> Paul Davis wrote:
> 
> > Paul Davis wrote:
> >
> >> Paul Davis wrote:
> >>
> >>> On Wed, 2005-10-12 at 00:17 -0500, the other Paul Davis wrote:
> >>>> The complexities abound.  Insert apropriate quote here.  I can't 
> >>>> explain the gtk drawing system because I don't entirely understand 
> >>>> it.  I'm glad hings are working.
> >>>
> >>> there is really nothing mysterious is you remember one simple rule:
> >>>
> >>>     draw on your widget's window ONLY in an expose event handler.
 
 [ ... ]

> >> Anyway, I agree exactly with what Other Paul is saying.  I just don't 
> >> know why it's so.  Other than its the way things were intended.

it all goes back to the basic idea of:

	1) X's server/client structure
	2) basic event loop programming

(1) is important. For example, if you change the stacking order of two
windows, the X server sends an "expose" event that specifies precisely
the rectangle of the lower window that now needs to be redrawn (because
it is on top). 

Notice that it is the X server that decides what needs to be drawn on
the screen, not your application. By "what", I mean which sections of
pixels, not the contents of course. Therefore, it makes no sense to
write applications around an API that pretends that the application
controls rendering to the screen. The X server dictates what sections
are redrawn at all times, and each time it makes a decision that
potentially requires the client to redraw some or all of its window(s),
it sends the client one or more suitable expose events.

(2) now, there are times when an application decides (because a timer
has expired, or because new data has arrived, etc etc) that it needs to
redraw some or all of its window(s) all by itself. but remember: the
application doesn't control the screen - all it can do is to send a
request to the server to change the contents of a given window. The
server of course can't do that by itself - all it can do is to send an
expose event to the relevant client and ask it to redraw that section.

so, rather than come up with two entirely different models for "how and
when to redraw", GTK and almost all other X-inspired GUI toolkits have
unified the model. If the X server needs you to redraw, it sends your
application an "expose" event telling you about what needs to be
redrawn. If you need to redraw, you ask the toolkit to arrange for you
to get an expose event corresponding to the area you need to redraw.
Because delivery of this event is integrated into the overall event
handling loop, things go smoothly. Moreover, your code has only a single
location where redrawing happens, making it simpler to read, understand
and maintain.

GTK has been ported to platforms where there is no X server in control
of the screen, but this paradigm appears to work well there too.

--p