roy@phri.UUCP (02/24/87)
I have two questions about the SunView pixrect package.
First, is there an easy way to find the bounding box of a memory
pixrect? By this I mean the smallest rectangle which encloses every
non-zero pixel in the pixrect. We are trying to make movies on a Sun-3 by
doing screendumps of the frames we want and then doing screenloads of each
in turn.
I have a little program which pr_load's all the screendump files
and then pr_rop's them to /dev/fb one at a time, which works fine up to
about 10 frames; then you run out of physical memory (on a [4-Meg] 3/50)
and start thrashing. As long as you have enough physical memory, you can
zap frames up on the screen plenty fast, but a 1 second movie isn't much
fun. Most of the frames don't come close to the edges of the screen, so we
could save a lot of core by just storing the area enclosed by the bounding
box, and an x,y offset from the origin of the screen.
The only way I can see to find the bounding box is by brute force
raster scanning of the pixrect using pr_get(), but this is bound to be
slow. Is there a faster way?
My second question concerns drawing dashed vectors. I want to
create a rubber-band effect (you paste down one endpoint of a vector, and
drag the mouse to the other endpoint, with a dashed vector being drawn so
you can see what it will look like when you release the mouse button).
I tried the obvious way and drew the vectors through a 50% grey
screen using pr_stencil, but the results are horrible looking and terribly
slow as well. What I really want is a way to say "draw this vector with 10
pixels on, 10 pixels off, where the on-off pattern goes by arc length
instead of x and y coordinates", just like PostScript's "setdash" operator.
Actually, I then want to XOR this with a pixrect, so I can erase it easily
when the mouse moves. My first though was to dive into pr_vector source
and modify it to do what I want, but that would leave me with something I
couldn't distribute except to other people with source licenses.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
"you can't spell deoxyribonucleic without unix!"mark@mimsy.UUCP (02/25/87)
In article <2601@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > I have two questions about the SunView pixrect package. > > First, is there an easy way to find the bounding box of a memory >pixrect? ...The only way I can see to find the bounding box is by brute force >raster scanning of the pixrect using pr_get(), but this is bound to be >slow. Is there a faster way? If you are using pr_load then you have got memory pixrect, and their representation in memory is guaranteed and documented (in the Pixrect Reference guide). You can essentially deal with the pixels as an array of shorts, which is much faster than using pr_get(). > > My second question concerns drawing dashed vectors. > SunOS 3.2 has a dashed (and other shaped) vector primitive that was not there in previous versions. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 After May 1, 1987: weiser@xerox.com
david@sun.UUCP (02/25/87)
Disclaimer: These are my personal opinions and Sun Microsystems would be just as happy if I never read news... In article <2601@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > I have two questions about the SunView pixrect package. SunView and pixrects are two different packages. >We are trying to make movies on a Sun-3 by >doing screendumps of the frames we want and then doing screenloads of each >in turn... Why don't you just have the program which computes the frames write rasterfiles itself with pr_dump, or write your own screendump which takes x, y, w, h arguments? > The only way I can see to find the bounding box is by brute force >raster scanning of the pixrect using pr_get(), but this is bound to be >slow. Is there a faster way? Sure. You can use a series of rops to efficiently "or" large areas into a single pixel for testing. It only takes log2 n + log2 m rops to smash an n x m area into a single pixel. (For more ideas on creative uses of rasterops, read the blue Smalltalk book.) The memory pixrect image data format is documented, so if you want to get your hands dirty you can scan through it yourself. Watch out for scan-line padding! (You didn't ask, but I think you would be better off storing the frames in memory in a simple run-length encoded format and expanding them on the fly for display.) > My second question concerns drawing dashed vectors. I want to >create a rubber-band effect (you paste down one endpoint of a vector, and >drag the mouse to the other endpoint, with a dashed vector being drawn so >you can see what it will look like when you release the mouse button). Support for textured vectors was introduced in SunOS Release 3.2. Upgrade thyself! -- David DiGiacomo {decvax, ihnp4, ucbvax}!sun!david david@sun.arpa Sun Microsystems, Mt. View, CA (415) 691-7495
hutch@sdcsvax.UUCP (02/27/87)
<>
include <pixrect/pixrect_hs.h>
struct pixrect *frame;
int high, wide;
... initialize with pr_open(), pr_load(), etc. ...
wide = frame->pr_width;
high = frame->pr_height;
As to your lines, why not just use simple XOR? O.k, O.k,
artistic ability must not be humbled. Well, how about replrop?
Make a small 4 box checkerboard and then use it as the source
for very narrow boxes (1 by x AND y by 1). That would do the
trick since you are only rubberbanding boxes.
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hutch@sdcsvax.ucsd.edu
Never seems to be enough resolution, memory, or speed, now why is that?roy@phri.UUCP (02/28/87)
In <2601@phri.UUCP> I asked 1) how do I find the BoundingBox of an image in a pixrect and 2) how do I draw dashed vectors. In <2769@sdcsvax.UCSD.EDU> hutch@sdcsvax.UCSD.EDU (Jim Hutchison) writes: > include <pixrect/pixrect_hs.h> > struct pixrect *frame; > int high, wide; > ... initialize with pr_open(), pr_load(), etc. ... > wide = frame->pr_width; > high = frame->pr_height; This will find the size of the pixrect, which is *not* the same as the BoundingBox. The BoundingBox is the smallest rectangle which encloses all the *not-zero* pixels. Imagine a totally blank screen, except for a single dark pixel in the middle. Using the above method, you will get wide and high set to the size of the screen. The size of the BoundingBox, however, is 1 x 1. > As to your lines, why not just use simple XOR? O.k, O.k, > artistic ability must not be humbled. Well, how about replrop? > Make a small 4 box checkerboard and then use it as the source > for very narrow boxes (1 by x AND y by 1). That would do the > trick since you are only rubberbanding boxes. If I was only rubberbanding boxes (i.e. horizontal and vertical lines) this would work fine, and is essentially the same as what I did when I tried pr_stencil'ing through a 50% screen. The problem is that I want to do arbitrary vectors. This method gives ugly results at odd angles; in fact, at 45 degrees, the vector either is pure white or pure black, depending on the phase of the screen. On the other hand, I will want to rubber-band boxes eventually, and this sounds like a good way to do it. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
hutch@sdcsvax.UUCP (02/28/87)
In article <2605@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
<..>>..
<> As to your lines, why not just use simple XOR? O.k, O.k,
<> artistic ability must not be humbled. Well, how about replrop?
<> Make a small 4 box checkerboard and then use it as the source
<> for very narrow boxes (1 by x AND y by 1). That would do the
<> trick since you are only rubberbanding boxes.
<
< If I was only rubberbanding boxes (i.e. horizontal and vertical
<lines) this would work fine, and is essentially the same as what I did when
<I tried pr_stencil'ing through a 50% screen. The problem is that I want to
<do arbitrary vectors. This method gives ugly results at odd angles; in
<fact, at 45 degrees, the vector either is pure white or pure black,
<depending on the phase of the screen. ...
Ummm, I speakee the english weakly on occasion :-). pr_stencil is very
slow, it demands a lot of the frame buffer computation, where as
replrop is just cut and repeat which is relatively fast. How about
this pattern. White noise. Would look funky, but no bad holes.
Admittedly not all that pleasent, but usable? I do a bit of fiddling
on a sun 2/150, which has no source pixrect for vectors, so please
pardon my earlier posting.
-
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hutch@sdcsvax.ucsd.edu
2049 6d61 7320 6c65 2066 6572 7270 7365 6e65 6974 676e 6920 206e 6874 7369 6120
7472 6369 656c 202c 2049 6572 7270 7365 6e65 2074 6e6f 796c 6d20 7379 6c65 2e66