Path: utzoo!attcan!uunet!mcvax!unido!ecrcvax!andy
From: andy@ecrcvax.UUCP (Andrew Dwelly)
Newsgroups: comp.windows.news
Subject: Re: retained canvases - application writers please read
Keywords: portability
Message-ID: <665@ecrcvax.UUCP>
Date: 12 Jan 89 09:21:57 GMT
References: <24631@sgi.SGI.COM>
Reply-To: andy@ecrcvax.UUCP (Andrew Dwelly)
Organization: ECRC, Munich 81, West Germany
Lines: 58

In article <24631@sgi.SGI.COM> msc@ramoth.SGI.COM (Mark Callow) writes:

>Almost every NeWS application that I have seen that uses retained canvases
>fails to respond correctly to /Damaged events.  The most common problem is
>that the program paints into an unmapped retained canvas then maps the
>canvas.  The program expects mapping to cause its bits to be transferred
>to the screen from the retained buffer.
>
> [Quotes from the 1.1 manual supporting, deleted]

Mark is absolutely correct, but as a writer of (research) applications I 
feel that this is one of the aspects of NeWS that I like the least. Making
the application keep track of where everything is, in order to be able
to redraw it, obviously makes life considerably more complex. Since in
my case, the creations are merely prototypes, and keeping them understandable
is a requirement, I (Oh Heresy!!) usually just ignore this and make everything
retained.

-- I did once try an experiment though. I wrote a program (unfortunately
unavailable now) which associated an array with a canvas. I had several
routines to draw items on the canvas, and each time they were called, they
carefully stored the details in the array. A separate process used this
array to recreate damaged portions of the canvas. The most important routine
was /Clear which cleared the canvas, and the array, otherwise redrawing
an picture that had been changed a lot, produced a sort of complete history
of the canvas.

Eventually I gave up with this approach. NeWS 1.1 appears to have a number of
bugs concerning arrays of length > 255 elements, causing strange effects
with some of the larger drawings. Secondly I found that the redrawn parts
did not match the existing parts quite accurately, often the difference was
only a pixel or so, but the effect was noticable and disturbing.

The final problem was that the whole process was rather slow. In order to
mend some damage, I set the damage path, and re-executed the entire history.
NeWS seems to just blindly execute every command, without even checking
whether a particular command is trivially outside of the clip area. Thus
redrawing a small portion of a complex drawing was as slow as redoing the
entire canvas, - real slooow.

A good idea, defeated by bugs, and my own lack of experience with the system.
There may be something useful here for future versions though. Possibly this
could even be introduced as a new sort of canvas (virtually-retained ?) at
the implementation level. Rather than storing the results of PS execution
on a bitmap, it just stores the commands for re-execution later. Lack of
referential transparency in the PS language, probably restricts the number
of commands that can successfully be used with such a canvas.

Comments ?

Andrew Dwelly                 
E.C.R.C.                                       UUCP: mcvax!unido!ecrcvax!andy
ArabellaStrasse 17 			       or    pyramid!ecrcvax!andy
D-8000 Muenchen 81, West Germany 	       UUCP Domain:  andy@ecrcvax.UUCP

[Bump, Crash ......
 Listen; who swears ?
 Christopher Robin has fallen down stairs.]