srt@CS.UCLA.EDU (Scott Turner) (04/12/88)
Anyone know how to use this godforsaken call to write a bitmap out to a file and then restore it? Incidentally, another fine example of Apollo documentation. -- Scott Turner
srt@aero.ARPA (Scott R. Turner) (04/15/88)
In article <srt@maui.cs.ucla.edu> srt@CS.UCLA.EDU (Scott Turner) writes: >Anyone know how to use this godforsaken call to write a bitmap out to >a file and then restore it? > >Incidentally, another fine example of Apollo documentation. Thanks to everyone who sent help. The problem turned out to be that the bitmap file doesn't actually get written out (in the case of using this call to create a bitmap file) until you explicitly deallocate the appropriate bitmap descriptor. 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, and there is no indication in the documentation of the "open" call what achieves these functions. Second, there is confusion between opening/reading/writing/closing the bitmap *file* and opening/reading/writing/closing the *bitmap*. I think the intent is to conceal the reading/writing of the *file* in the reading/writing of the *bitmap*. That is, gpr_$open_bitmap_file returns a bitmap descriptor (an access structure for the *bitmap*) and then reading/writing this *bitmap* has a concealed side-effect: reading/writing the bitmap *file*. In general, hidden side-effects of this sort are a Bad Idea, and especially when there is a conceptual confusion of the sort that exists here. Many programmers might not even realize the difference between the bitmap and the corresponding file. 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. 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. -- Scott Turner
oj@apollo.uucp (Ellis Oliver Jones) (04/16/88)
In article <880412.034912z.10599.srt@maui.cs.ucla.edu> srt@CS.UCLA.EDU (Scott Turner) writes: >Anyone know how to use this godforsaken call to write a bitmap out to >a file and then restore it? Well, it doesn't "write a bitmap out to a file," but rather creates a permanent bitmap---one that lives in a file. If you want to save a pre-existing bitmap you should (a) create and open the bitmap file with gpr_$open_bitmap_file and (b) use gpr_$pixel_blt to copy the bits from your pre-existing bitmap into the new one. Incidentally, you can save the *entire* screen into a bitmap file using /com/cpcsr . Does this help? >Incidentally, another fine example of Apollo documentation. The GPR docs I have are labelled June 1987, and their writer did quite a lot of work a year a ago to improve them. In particular, GPR_$OPEN_BITMAP_FILE is described in quite a bit of detail. Do you have the latest docs? /Ollie Jones (Speaking for myself, not necessarily for Apollo Computer, Inc.)
oj@apollo.uucp (Ellis Oliver Jones) (04/18/88)
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.)