Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!usc!apple!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  XtRealizeWidget() - Why does it work as it does?
Message-ID: <9006131034.AA20583@Larry.McRCIM.McGill.EDU>
Date: 13 Jun 90 10:34:10 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 34

> What's confusing me is the sequence of activities when realizing a
> composite widget.  The fcn that actually does the work,
> RealizeWidget(), is recursive, and it walks down the widget tree from
> parent to child.  It seems to do a lot of stuff on the way down, but
> not actually map anything.  It maps on the way back up, as the
> recursive calls return.  This means it maps children first and
> ancestors later.

Okay so far...

> Which means you first draw all the children on the screen and then
> draw the parent _around_ them.

...whoops.  No, the children don't actually become viewable[%] until
not only they but also all their ancestors are mapped.  The whole thing
is built off-screen until the topmost window is mapped, at which point
it all appears *poof!* at once.

Granted, your argument still stands: the parent has to be drawn in lots
of little pieces.  But the clipping code is *fast* (it has to be), and
most of the time the visible area of the parent is relatively simple
(just a few rectangles), making it even faster.  I think the visual
effect of the whole thing appearing at once is worth more than saving a
few cycles by mapping top-down.

[%] I would have said "show up on screen", but other applications'
    windows[$] may obscure it.

[$] Or even other top-level windows from this same application.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu