nanogui: Thread: xpm display on mono pda

Hi all,
	I'm working on a NEC vr4181 , mono LCD.
	When I port a small flnx program to it, I find that
the xpm display is very slow, the image size is
120x120, and I waited about 1 minute to see it be on
the screen. 
	Can you do something to speed display image up?
	If I want to do something special to nano-x mono
display, which file should I look for?
	BTW, I think there are too few documents about the
source code.

Best reguards,
Yi,yang

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

yi yang wrote:
> 
> Hi all,
>         I'm working on a NEC vr4181 , mono LCD.
>         When I port a small flnx program to it, I find that
> the xpm display is very slow, the image size is
> 120x120, and I waited about 1 minute to see it be on
> the screen.
>         Can you do something to speed display image up?

Yep, it is a bit slow, depending on your system and your processor
speed.  One thing you can to to speed it up
is to use the XPM renderer in Microwindows instead of FLNX, which will
cut down on some of the time it takes to
draw.   Probably a good chunk of the time is spent reading the file and
processing the colors (which is a pain in
the rear).  Microwindows helps by pre-loading the image, so you can
process it once, and display it many times.
I think the FLNX version processes each image individually, so thats
where the speed comes from.  Take a look at the
pixmap code in FLNX and see if you can't convert over to the standard
GrLoadImageFromFile and GrDrawImageToFit calls in Nano-X.

>         If I want to do something special to nano-x mono
> display, which file should I look for?

It depends on what you want to do.  Pick an area to concentrate on, and
we'll be more specific.

>         BTW, I think there are too few documents about the
> source code.

Nano-X?  Yes, we are lacking in documentation.  FLNX?  Go to
www.fltk.org for a full API list and documentation.
 
> Best reguards,
> Yi,yang

Happy holidays,
Jordan
 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Tue, 19 Dec 2000, Jordan Crouse wrote:
> Nano-X?  Yes, we are lacking in documentation.  FLNX?  Go to
> www.fltk.org for a full API list and documentation.

There will be a Nano-X API reference in pre7. I've put a copy of it up at:
http://www.linuxhacker.org/pub/nanogui/nano-X-API.tar.gz
ftp://ftp.linuxhacker.org/pub/nanogui/nano-X-API.tar.gz

There's also a PDF version and a PS version there...

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

: > the xpm display is very slow, the image size is
: > 120x120, and I waited about 1 minute to see it be on
: > the screen.
: >         Can you do something to speed display image up?

As Jordan mentions, you might want to use the GrDrawImageToFit
function and have the Microwindows server decode the image.

However, I think one of the current reasons that image drawing
is slow here is that images that are decoded to 16, 24 or 32bpp
have to do a truecolor->palette index conversion for each pixel,
which is slow as hell.  There are three fixes for this:

1. Recode XPM decoding to convert to a current system palette
index.

2. Recode the entire image decoding system to decode to the
hardware bits per pixel.  I'm working on this, and plan to finally
release new blitting code and decoders for the image routines,
which will greatly speed up image display for Nano-X.  In addition,
I plan on adding the alpha-channel and src/dest color-key blits as well.

3. Change the 1bpp or 2bpp display to truecolor in Microwindows,
rather than palettized.  Although Microwindows doesn't quite support this,
with some mods the truecolor->palette index lookup would then
be a mask and bit shift to get to the grey scale color, and things
would be quicker.

Regards,

Greg

Greg Haerr wrote:
> 
> 1. Recode XPM decoding to convert to a current system palette
> index.

Well, since XPMs are palettized to begin with, it is a easy thing to
store the RGB palette (which we do with systems that have with 8 bits or
less of color support). However, it would be nice to do the color
matching when we decode the file instead of when the image is drawing.

But I still think that the problem lies in FLNX.  We didn't have XPM
support when the FLNX code was written, so the widget decodes the file
on its own.  This should probably be converted over to use the
microwindows code.

> Regards,
> 
> Greg