Path: utzoo!attcan!uunet!munnari!murtoa.cs.mu.oz.au!mwp@murtoa
From: mwp@murtoa (Michael Paddon)
Newsgroups: comp.windows.news
Subject: Re: retained canvases - application writers please read
Message-ID: <1154@murtoa.cs.mu.oz.au>
Date: 11 Jan 89 14:31:01 GMT
References: <24631@sgi.SGI.COM>
Sender: news@cs.mu.oz.au
Reply-To: mwp@murtoa
Lines: 34

From article <24631@sgi.SGI.COM>, by msc@ramoth.SGI.COM (Mark Callow):
> 
> However to quote the NeWS manual Section 2.2, Page 14
> 
> 	"All programs have to cope with damage and must be able to
> 	reconstruct the damaged part" ... "retained canvases are
> 	purely a performance enhancement".

Sometimes it is extremely useful to have a canvas that you
*know* is retained. This, in fact, can be achieved under NeWS.

To quote the NeWS 1.1 "READ THIS FIRST" document, Page 8

	"One exception to this rule (that the NeWS server may ignore
	retained hints) is that the NeWS server must honor the
	/Retained setting of parent-less canvases"

I presume that a parent-less canvas is one with a null value in
its /Parent entry, although this is not explicitly stated. Note
that any canvas may be made parent-less at any time.

The major drawback of using parent-less canvases is that the
functions of the window hieracrchy are not available (ie. child
canvases moving with parent; child canvases clipped by parent).
It's not at all clear why Sun defined this one special case for
retained canvases. It would be much more useful to make the
/Retained entry tri-valued (yes, no and maybe) so that if you
*really* want offscreen bitmaps you don't have to write bizarre
code.

========================================================
| Michael Paddon (mwp@munnari.oz.au)                   |
| Department of Computer Science, Melbourne University |
========================================================