Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request
From: david@sun.com
Newsgroups: comp.sys.sun
Subject: Re: Pixrect line padding
Keywords: Windows
Message-ID: <4010@brazos.Rice.edu>
Date: 20 Dec 89 08:57:40 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 25
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n217
X-Sun-Spots-Digest: Volume 8, Issue 229, message 3 of 16

In article <3789@brazos.Rice.edu> canon!laukee@nsfnet-relay.ac.uk (David
Lau-Kee) writes:

>X-Sun-Spots-Digest: Volume 8, Issue 217, message 12 of 23
>My 4.0.3 documentation says
>that for pixrects of width > 16 scan lines are padded out to a 32 bit
>boundary.

Read the documentation carefully -- this is describing pixrects created by
mem_create().  The minimum padding requirement is still 16 bits.

>This means that MPR_LINEBITPAD ought to be 32, and that the
>mpr_linebytes macro (which will take your *actual* width and depth and
>return the number of bytes you need to hold a whole line) gets it wrong
>(unless your bitmap happens to be < 16 bits wide or a multiple of 32!).

Not really.  We couldn't change MPR_LINEBITPAD without breaking everyone's
mpr_static() declarations etc.  All the pixrect code is still capable of
handling 16 bit padded pixrects, but on SPARC systems they're much less
efficient.  It's better to use 32 bit padded pixrects if you can.

P.S. Whenever you want to access the data in a memory pixrect, look at
md_linebytes instead of assuming a particular padding algorithm.

David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david@eng.sun.com