chernoff@cartan.berkeley.edu (06/19/88)
I would like to know why the Sun pixrect operation for copying a "vertical" rectangle of a given size (say 1 by 500) takes much longer than the corresponding operation for copying a "horizontal" rectangle (say 500x1). For example, the obvious c program to flip the screen top-bottom by reshuffling horizontal lines runs much, much faster than the analogous program to flip the screen left-right by reshuffling vertical lines. (I imagine this has something to do with hardware; I am using a Sun 3/50 (without any special graphics hardware).) ********************************************************* * Paul R. Chernoff chernoff@cartan.berkeley.edu * * Department of Mathematics ucbvax!cartan!chernoff * * University of California * * Berkeley, CA 94720 *
naughton%wind@Sun.COM (Patrick Naughton) (06/21/88)
Paul Chernoff (chernoff@cartan.berkeley.edu) wrote: > > I would like to know why the Sun pixrect operation > for copying a "vertical" rectangle of a given size > (say 1 by 500) takes much longer than the corresponding > operation for copying a "horizontal" rectangle (say 500x1). and Chuck Brunow (loci@csccat.uucp) replied: > Probably because a raster is "horizontally" oriented in RAM. > Writeing 500 pixels across means memory in sequence, whereas > vertical writes must do a mapping computation for each line. > > At least that's the way that other machines work (unix-pc, > various ibm graphics. etc.) but I'm not sure about Sun's. While it is true that the address calculation for the next scanline takes longer than the calculation of the next byte, (y += bytes_per_scanline vs. y++) the more significant reason for the speed difference between a "flip horizontal" and a "flip vertical" is the bit operations, (rotate and shift) that must be performed on the horizontal version. To flip vertically, all operations are on byte (or other machine word) sized objects. These operations are "cheap" as they move 8 (or more) pixels to the desired position in one instruction. To flip horizontally, the bits in the byte (or other word) must be reversed. On most architectures, this requires more than one instruction, and in fact, usually a loop of n, where n is the machine word size. It is important to note that this is only an issue with bit-mapped displays. That is, each bit in a given display byte represents a pixel, which will be light or dark depending on its value, (1 or 0). If you are dealing with a color display such as a Sun CG2, where each pixel is represented by a byte, which is in turn a pointer to a 256 entry RGB color LUT, there will be no performance difference between horizontal and vertical flips since no bit operations are required. Patrick J. Naughton ARPA: naughton@Sun.COM Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: 415/336-2979 /\ \ \ Sun Microsystems, Inc \ \ \ 2550 Garcia Avenue \ \ \ Mountain View, CA 94043 / \ \ / (415) 960-1300 / / \/ / / (415) 336-2979 / / /\ / / /\ TLX 287815 \/ / / \/ / / / / /\ / / Patrick J. Naughton / \ \ / Software Engineer \ \ \ Window Systems \ \ \ \ \ Sun!naughton || naughton@Sun.COM \/
david@sun.uucp (David DiGiacomo) (06/21/88)
In article <11115@agate.BERKELEY.EDU> chernoff@cartan.berkeley.edu (Paul R. Chernoff) writes: >I would like to know why the Sun pixrect operation >for copying a "vertical" rectangle of a given size >(say 1 by 500) takes much longer than the corresponding >operation for copying a "horizontal" rectangle (say 500x1). It's because successive horizontal pixels are part of the same memory word and can be manipulated as a unit. On monochrome frame buffers ("bw2") 32 horizontally adjacent pixels can be read or written with one memory access. On 8 bit color frame buffers there are 4 ("cg4") or effectively 2, 4, or 16 ("cg2" frame buffers with rasterop chips) pixels per memory word. Reading a 500 pixel vertical stripe from a monochrome frame buffer requires 500 memory accesses as opposed to only 16 accesses for a horizontal stripe. (Operating on a single bit within a word also requires additional shift/mask effort, but the most significant factor is the number of memory accesses.) -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com