knudsen@ihwpt.ATT.COM (mike knudsen) (04/27/87)
A very useful property of Level 2's PUT/GET graphics
buffers is that they outlive both the paths and the procs
that create and load them. One proc can create and fill
some buffers, and a later proc can come along and use them.
Within their original purpose, the first program can draw
lots of images. icons, etc into buffers and go away.
Then your application can use the stuff without losing
precious RAM to the first program.
Now maybe some whiz can figure a way to get at those
buffers to read their contents, thus making them useful
for non-graphics work, or for storing graphics drawstrings.
(Something better than PUTting the buffer to a deselected
graphics screen, mapping that screen into memory and
reading the bytes out.)
This would make a reasonable substitute for the "shared data
modules" supposedly available in Level 1 -- I've never met anyone
who claimed to have created and used such a beast.
Of course the two or more programs must agree on group
and buffer numbers, and size of things put into them.
Also a buffer must be KILLed before anything new can be
GOT into it that is bigger (in bytes) than that buffer was
originally created.
PS: A useful utility would be a way to dump a buffer to
a disk file or stdout, the opposite of the LOADBUF (sp?)
operation. This would make an "icon editor" easier to
write.
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
" ~E(x):[is_lunch(x) && cost(x)==0] "