gtc@cup.portal.com (greg t chalfin) (06/11/90)
I'm trying to understand how XtRealizeWidget() works, and something seems strange about it. (I'm probably missing something.) 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. Which means you first draw all the children on the screen and then draw the parent _around_ them. But this doesn't seem sensible, as it puts a big burden on the drawing software (or hardware), since the parent has to be drawn as a lot of little pieces to avoid overwriting any children. Like I said, I'm probably missing something. Can anybody tell me what? Thanks in advance for any hints. ---Greg
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (06/13/90)
> 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
matsj@delfi.UDAC.UU.SE (Mats Johnson) (06/15/90)
In article <30684@cup.portal.com> gtc@cup.portal.com (greg t chalfin) writes:
I'm trying to understand how XtRealizeWidget() works, and something
seems strange about it. (I'm probably missing something.)
...
It maps on the way back up, as the recursive calls return.
This means it maps children first and ancestors later.
I'd say that's because mapping a child of an unmapped parent does not
actually map the child onto the screen, it only has the effect that
the child will be mapped whenever the parent is.
--
------
Mats Johnson, UDAC, Box 2103, S-750 02 Uppsala, SWEDEN. Phone +46 18-187858
E-mail: matsj@delfi.UDAC.UU.SE