culmer@eniac.seas.upenn.edu (Charles Culmer) (02/12/89)
I inherited a model 3000 last week and started playing with gpr. Please excuse me for asking some really novice questions. (I'm using version 9.7.) (1) Is there any way to turn on a single pixel besides drawing a line of length 0 with gpr_$line? Why isn't there gpr_$pixel? (I wanted to write a program to draw the chaos triangle shown on a recent episode of Nova.) (2) I want to draw pictures larger than the screen and move them around under my window. A brief skim of the gpr manual suggested that frame mode was the way to do it, but the manual recommended against using frame mode. What should I do? Do I build a bitmap in main memory and then do transfers as I move the window? Isn't that what frame mode does? I hardly expect to do it better than the professional programmers and basketball gurus at Apollo. Thanks. Charles W. Culmer culmer@eniac.seas.upenn.edu Truth, justice, and the American way.
oj@apollo.COM (Ellis Oliver Jones) (02/23/89)
In article <7892@netnews.upenn.edu> culmer@eniac.seas.upenn.edu (Charles Culmer) writes: >Please excuse me for asking some really novice [gpr] questions. No need to apologize....thanks for your interest. >(1) Is there any way to turn on a single pixel besides drawing >a line of length 0 with gpr_$line? Why isn't there gpr_$pixel? There is gpr_$write_pixels, which lets you pour pixel values into a rectangle. The 1x1 case of this call is oft-used for what you want to do, and it's not grotesquely inefficient. Neither is a line of length 0 grotesquely inefficient. I don't know why there isn't a gpr_$pixel call similar to XDrawPixel and XDrawPixels. It's not a bad idea. Stick with unobscured windows at sr9.7 if you're using gpr_$write_pixels. You don't say whether you have a mono or color node, nor how many planes you have. You can gain direct virtual memory access to any one plane of your node's display memory, however, by using gpr_$remap_color_memory (to select which plane), gpr_$inq_bitmap_pointer (to find out the virtual address of the video memory) gpr_$inq_bm_bit_offset (to find out which bit within the video memory starts your window ) gpr_$enable_direct_access (to switch on the direct virtual memory access mode) This is a bit complex, but once you've got it figured out, it's blazingly fast for random single-plane pixel access. >(2) I want to draw pictures larger than the screen and move them >around under my window. A brief skim of the gpr manual suggested >that frame mode was the way to do it, but the manual recommended >against using frame mode. What should I do? Do I build a bitmap >in main memory and then do transfers as I move the window? You can try frame mode. The best thing to do is (a) initialize gpr in frame mode. In the gpr_$init call, specify the size of your whole picture (yes, bigger than the onscreen pad). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (b) create a main memory bitmap the size of your whole picture. (c) Draw the picture into this main memory bitmap. (d) Use gpr_$pixel_blt to draw the main memory bitmap--the whole thing! into your frame. (e) "Scroll around the grounds until you feel at home" with the arrow keys. (f) When you're done, call gpr_$terminate, and make sure you specify TRUE for the delete_disp Boolean parameter... you can't leave bitmaps in your transcript pad. This should work, if you hack around for a while ...it's what DSEE does for "show derivation." The manual says not to use frame mode because (a) it's much more limited in what really works than direct and borrow modes. (b) it's slow (c) it's kludgy..basically it works by inserting funky secret escape sequences into the transcript pad's byte stream. For what you're trying to do, it should be OK, though. Give it a try. >I hardly expect to do it better than >the professional programmers and basketball gurus at Apollo. Keep talking that way and you may get awarded a hunk of Boston Garden parquet floor! We'd have to rip it off first, though! :-) /Ollie Jones (speaking for myself, not necessarily for Apollo Computer, Inc.)
pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson) (02/24/89)
Another dumb GPR question... well, maybe not so dumb, but it keeps coming up in my code, and I haven't found a good solution: Is there an extremely fast, efficient way of converting a pixel major bitmap to a plane major bitmap and vice versa? ie many printer type devices want things an 8 bit pixel at a time, but are stored a plane at a time. The best I've been able to do is to do a gpr_$read/write_pixels, which gives me a pixel per 4 byte array element. I do this only on one row or column at a time (a column is much slower than a row), since to convert a plane bitmap to a pixel bitmap via this call is beyond the given limit of 128K pixels (this last info from my memory). I don't recall exactly how fast I can do it, but it is something on the order of a minute or two. Is there a faster way of doing this? Paul Anderson CAEN Apollo guy