nanogui: Images not drawn (FLTK+nxlib app with nano-X)
Subject:
RE: [nanogui] Images not drawn (FLTK+nxlib app with nano-X)
From:
"Martin Kajdas" ####@####.####
Date:
3 Feb 2006 16:19:44 +0000
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC22914C2@mkmail.MKPROD.COM>
Greg,
The image is a PNG file (24x24 pixels) but because I use FLTK, it converts it (I believe) to RGB 5:6:5 image array (24x24 words) before it calls XPutImage().
The nxlib calls putTrueColorImage() with this array which eventually is passed to GrArea with following parameters:
width = 24
height = 24
dest_x = 0
dest_y = 0
src = pointer to array of 24x24 words (data looks like correct 5:6:5 RGB)
mode = 5 (MWPF_TRUECOLOR565)
image->depth = 16
image->bytes_per_line = 48
image->bits_per_pixel = 16
To me these values look correct but the nano-X displays only 16x24 partial image. Other than being clipped, the image is correct.
If the image was 32x24 it would display fully.
If GrArea converts MWPF_TRUECOLOR565 to MWPF_RGB format then that is where the problem is.
Let me know what can I do next.
Martin
-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, February 02, 2006 5:00 PM
To: Martin Kajdas
Cc: ####@####.####
Subject: Re: [nanogui] Images not drawn (FLTK+nxlib app with nano-X)
> 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
