Pitch is NOT the number of bytes per line. Sometimes that is true, sometimes it isn't.
Pitch is the total number of bytes, rounded up to the nearest multiple of 4 (or whatever the alignment is), that is needed to contain a single row of pixels.
When you create the pixmap, if the `alignment` is 4, that means you want the start of each row to begin on a 4-byte aligned memory address. The amount of bytes per row needed to achieve this is the Pitch, which may be more than the total number of bytes taken up by actual pixel data.
With Alignment of 1, LIMINENCE format, Pitch=Width*BytesPerPixel
With Alignment of 4, LIMINENCE format, Pitch=Width*BytesPerPixel rounded up to the nearest multiple of 4
You'll notice, though, that if you have a RGBA or ARGB format pixmap, because each pixel is a whole 4 bytes, it is ALWAYS aligned (regardless of whether alignment is 1 or 4), so Pitch WILL be the same as Width*BytesPerPixel.
The Pitch takes into account the requested alignment, which is usually 4. It's how many bytes you'd need to add to an address in the pixmap in order to get to the same X coordinate on the next row. Obviously if you have a 3x3 pixmap in RGB format, that's only 9 bytes of pixel data per row, so if alignment is 4 it will be increased to 12 bytes per row. So you'd have to add 12 to the pointer to get to the same X coord on the next row. That is, unless align=1, in which case you'd add 9.
A pitch is also an absolutely necessary device for allowing the system to handle `windows within pixmaps` and static pixmaps. To have a window within a pixmap, where the window is smaller than the original pixmap, you have to know how many extra pixels within the original you have to skip at the end of the window's row in order to get to the start of the next window's row. That's obviously going to be the original pixmap's pitch minus the window pixmap's pitch. Without a pitch you wouldn't be able to have windows within pixmaps - generally it defines the difference between where the pixels stop and where the memory space for the row stops.
Generally you'll want to use alignment of 4 for your pixmaps if you have a say in it, because this is more efficient for reading/writing the data. It also probably makes it faster for uploading textures or grabbing the backbuffer.
Pitch is the total number of bytes, rounded up to the nearest multiple of 4 (or whatever the alignment is), that is needed to contain a single row of pixels.
When you create the pixmap, if the `alignment` is 4, that means you want the start of each row to begin on a 4-byte aligned memory address. The amount of bytes per row needed to achieve this is the Pitch, which may be more than the total number of bytes taken up by actual pixel data.
With Alignment of 1, LIMINENCE format, Pitch=Width*BytesPerPixel
With Alignment of 4, LIMINENCE format, Pitch=Width*BytesPerPixel rounded up to the nearest multiple of 4
You'll notice, though, that if you have a RGBA or ARGB format pixmap, because each pixel is a whole 4 bytes, it is ALWAYS aligned (regardless of whether alignment is 1 or 4), so Pitch WILL be the same as Width*BytesPerPixel.
The Pitch takes into account the requested alignment, which is usually 4. It's how many bytes you'd need to add to an address in the pixmap in order to get to the same X coordinate on the next row. Obviously if you have a 3x3 pixmap in RGB format, that's only 9 bytes of pixel data per row, so if alignment is 4 it will be increased to 12 bytes per row. So you'd have to add 12 to the pointer to get to the same X coord on the next row. That is, unless align=1, in which case you'd add 9.
A pitch is also an absolutely necessary device for allowing the system to handle `windows within pixmaps` and static pixmaps. To have a window within a pixmap, where the window is smaller than the original pixmap, you have to know how many extra pixels within the original you have to skip at the end of the window's row in order to get to the start of the next window's row. That's obviously going to be the original pixmap's pitch minus the window pixmap's pitch. Without a pitch you wouldn't be able to have windows within pixmaps - generally it defines the difference between where the pixels stop and where the memory space for the row stops.
Generally you'll want to use alignment of 4 for your pixmaps if you have a say in it, because this is more efficient for reading/writing the data. It also probably makes it faster for uploading textures or grabbing the backbuffer.