Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!apollo!oj
From: oj@apollo.uucp (Ellis Oliver Jones)
Newsgroups: comp.sys.apollo
Subject: Re: Need Help with gpr_$open_bitmap_file
Message-ID: <3b8966e5.d5b2@apollo.uucp>
Date: 18 Apr 88 14:49:00 GMT
References: <880412.034912z.10599.srt@maui.cs.ucla.edu> <28975@aero.ARPA>
Reply-To: oj@apollo.UUCP (Ellis Oliver Jones)
Organization: Apollo Computer, Chelmsford, MA
Lines: 55
Keywords: GPR, bitmaps, virtual memory, documentation
Summary: Bitmaps are virtual memory

In article <28975@aero.ARPA> srt@aero.UUCP (Scott R. Turner) writes:
>In general this is a badly conceived and badly documented call.
>First, if you name something "open", a programmer naturally expects
>corresponding "write", "read" and "close" functions, none of which
>exist..

To "write" and "read" the bitmap file, you use standard gpr calls.
It just wouldn't make sense to supply something else, because the point
is to provide file-resident bitmaps that had the same capabilities as other
bitmaps (such as display bitmaps and hidden-display-memory bitmaps).

Main memory bitmaps are, basically, *identical* to file bitmaps except for
the fact that they live in anonymous address space, instead of files.

>I think the intent is to conceal the reading/writing of the *file* in
>the reading/writing of the *bitmap*. 

Actually, what we had in mind is this:
Each bitmap is a chunk (actually a few chunks, if you count
headers, color tables, &c) of virtual address space.  It's possible
to acquire that address space from the heap (using RWS_$ALLOC... or the
equivalent) or by mapping a file.  GPR_$OPEN_BITMAP_FILE is supposed
to map a bitmap file into a bitmap's virtual address space.

Thereafter, you can write and read the bitmap simply by accessing
that virtual address space, via direct access or via gpr calls for
drawing.  As you touch the virtual address space, you're also touching
the file.  So, in the GPR model of bitmap access, there isn't any
distinction between the "bitmap" and the "bitmap file" once the file is "open."

>Finally, if you design a system where there isn't a specific ``close
>and finish up I/O'' call, then the system should guarantee that the
>actual state of the I/O matches the expected state by the next
>possible check time.

Right.  The problem is flushing the cached pages of the virtual address space
back to the file system.  Deallocating the bitmap does that (although it's
not obvious).
We wouldn't want to force a cache-flush after each gpr operation to a file
bitmap.  Performance would suffer awfully, especially if the bitmap file storage
was remote from the node using it. 

When you know that the rules for accessing and sharing bitmap files are the
same as the rules for accessing and sharing virtual memory, then you're in good
shape.

>If you write to an external bitmap file and the
>documentation doesn't say you have to specifically close and update,
>then the file should be kept in accordance with the current state as
>maintained internal to the program.

In fact, the whole bitmap concept could stand to be better explained in the
documentation.  Thanks for your input, and your patience.

/Ollie Jones  (speaking for myself, not necessarily for Apollo Computer, Inc.)