nanogui: 16bit color depth in microwindows
Subject:
Re: Re(2): [nanogui] 16bit color depth in microwindows
From:
Jordan Crouse ####@####.####
Date:
30 Oct 2001 14:57:08 -0000
Message-Id: <E15yaK1-000330-00@ns.censoft.com>
So, basically you are saying that we need to be able to support 24 bit
bitmaps (those without a palette) in Microwindows? That shouldn't be too
hard to accomplish. Of course, its not always trivial to convert between
different depths, but we have some existing code that shows the way (the XPM
code handles conversion from the internal 24 bit mode).
Also so if there are some special API calls in Windows CE that we have not
yet been implemented in Microwindows, I don't see any reason why we shouldn't
try to flesh some of these out.
Jordan
On Tuesday 30 October 2001 06:42, William Mohat mentioned:
> Jordan / list:
>
> We have some software people in Latvia that are trying to help with
> this TRUECOLOR 565 problem. They have been able to get some images
> to work, but with some real contortions. Here is their description of
> what they have to do:
>
>
> " I am doing what I found in Wicrowindows examples.
> Unfortunatelly they haven't implemented *.rc (resource)
> files in Microwindows as I know them in Windows.
> Therefore
> to display some image on screen I found folllowing
> way. (In Windows, and also here all pictures are
> originally
> stored as .bmp files):
>
> convbmp picture.bmp
>
> That generates picture.c file. If bmp file is 256 color
> bitmap
> (as ones that I used) you can see pallete definition in
> this
> generated .c file. If you use 24bit bitmap as source,
> there
> are no pallete definition, each pixel is given by RGB
> values
> (I guess). I haven't tried how 24bit bitmaps looks on
> StrongARM,
> when converted and displayed with DrawDIB.
>
> Then by using special Microwindows function (there are
> no
> such equivalent in MS API)
>
> DrawDIB(hdc, 0, 0, &image_picture);
>
> I put bitmap on the screen. That was the only way I
> found how
> to get bmp on screen. If you know of some different,
> more
> efficient way to do this, let me know.
>
>
> The folks in Latvia report that this makes the code very non-portable
> between WInCE and LINUX/Microwindows. Does anyone have any
> experience with this? Is there a better way?
>
>
> Bill Mohat
> Telos Systems
>
> ####@####.#### writes:
> >I haven't had a problem with 565 to date, but there is always a first
> >time.
> >
> >A little background would be useful:
> >
> >Is the LCD black and white or color?
> >What processor are you running on (ie, could it be an endianism problem)
> >What chipset are you using (does it support 565 in the kernel framebuffer)
> >
> >Jordan
> >
> >On Monday 29 October 2001 14:51, William Mohat mentioned:
> >> I am trying to get the MicroWindows Framebuffer to handle
> >> 16 bits / pixel. (Specifically, TRUECOLOR565). The pallette
> >> translation works fine on X11 on my host PC-based system.
> >> However, the same image on our embedded system's LCD
> >> display (framebuffer) shows really screwed up colors.
> >>
> >> Does fb.c not handle TRUECOLOR565 correctly? If so, what
> >> must be done to fix this?
> >>
> >> Bill Mohat
> >> Telos Systems
> >
> >**************************************************************************
> >*
> >
> >>****8
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ####@####.####
> >> For additional commands, e-mail: ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
