nanogui: Images not drawn (FLTK+nxlib app with nano-X)
Subject:
Re: [nanogui] Images not drawn (FLTK+nxlib app with nano-X)
From:
"Greg Haerr" ####@####.####
Date:
3 Feb 2006 00:59:57 +0000
Message-Id: <0b5901c6285d$25ad6cf0$6401a8c0@winXP>
> I put many print messages into Image.c (putTrueColorImage()) to debug this
and I verified that the image size and the data is correct when calling
GrArea() function (width=height=24, 48x24 bytes of data match image).
Martin -
OK, I've been confused from the start, for some reason I was thinking
you were running monochrome... in which case the MWIMAGEHDR
bits are always padded to a word boundary.
However, you're saying you're running 565, which means that all images
are always word-multiples, so the problem you're having has nothing
to do with padding.
In looking at the nxlib Image.c source, I now see another problem area.
The big issue is the GrArea last parameter, which tells microwindows what
format the data is in. NOTE, that unlike all other image data with
microwindows,
where the image data must be in hw format (in your case 565), GrArea
allows conversion between any input format (MWPF_*) to the hw
framebuffer format. This is why GrArea is so slow, in that it actually
ends up drawing the pixels one by one, in most cases.
In one case of the NXLIB code, GrArea is called with MWPF_RGB.
This means the input data must be in 32bpp. In other areas, notably
putImage(), which is where your code path likely is, the image format
is determined from the Ximage->bits_per_pixel value. A switch
is then executed that grabs the colors from the Ximage palette,
and creates an MWPF_RGB GrArea arrray, and then calls
GrArea.
You'll need to closely follow this conversion, I think nxlib has a bug
converting from an XImage format to MWPF_RGB format. I'd
be interested to know what format the original XImage is in, and
whether the problems are in converting width values in the putImage
routine.
Regards,
Greg
