[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
'nother XLib Question
- To: firstname.lastname@example.org
- Subject: 'nother XLib Question
- From: Douglas Linder <email@example.com>
- Date: Tue, 12 Jun 2001 14:14:08 +0800
- Delivered-To: mailing list firstname.lastname@example.org
- Delivery-Date: Tue, 12 Jun 2001 02:16:35 -0400
- Mailing-List: contact email@example.com; run by ezmlm
- Newsgroups: sunsite.linux.linuxgames
- Organization: SunSITE.dk - Supporting Opensource Software
- Reply-To: firstname.lastname@example.org
Greets. : )
I have a tiny X lib question I'm justing dying to have some kind sole
who knows a lot about X windows answer for me. It's just for the good
old XCreateImage and XPutImage routines.
Very simple, I create an XYPixmap, and I draw it and get a seg fault. I
can't figure out why. The bitmap pad is 32, and the bytes-per-line is
set to (Image Width), which every color being represented by 8-bits in
the data. The data array is allocated and three times as big as it needs
to be (there are 3 frames in the image data, after each other (the data
gets loaded that way). I -was- going to just moving the pointer up and
pass the next chunk to the next call of XCreateImage, but I never got
I'm certain the rest of the program is fine; My drawing routines with
the GC and the basic stuff like drawing lines and boxes and arcs works
For reference, if it helps: The display depth its working on is 16 bbp.
Am I severely misunderstanding this? I played with Ximages before, a
while ago, but I got to this point then as well and decided it was too
tricky; but I -really- want to get this working this time.
Let's get back to the very basics. The bitmap pad is the size used in
the x server memory to hold the color information, right? It's 32 bit
because the X-server uses that internally (which is why you can plug
direct color straight into X server memory if that's what you want to
do). I actually get the 32 from BitmapPad (display), but it doesn't
An XY Pixmap consists of 3 color planes, R/B/G. Each color plane is the
set of pixal values for that color plane for a particular pixel. The
scan line is STILL only (image width) bytes wide, becuase the r/g/b data
is in 8-bit values.
Am I wrong? If this were a ZPixmap, the scan line would be (3*Image
Width) bytes wide, because the rgb are consecutive in a single plane. Or
so I think. Nb. I'm using an XYPixmap because the image format makes it
easier (& quicker) to load in planes rather than rgb clumped.
Well, thanks to anyone who can help! I know the ximage stuff is slightly
arcane, so many thanks to anyone who actually knows enough to help!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org