nanogui: Thread: Images and palette

Hi,

Im working on an 8bit, palettized, device.

When i display images, nano-X seems to modify the palette, but it doesnt
seem to be good at it.

I would like to have a fixed palette, that only the user changes, how can i
do that?

I already modified my config to have SCREEN_PIXTYPE=MWPF_PALETTE but it
doesnt seem to be enough. When I do that I would suppose that every call to
use some colors values is going to use the color value as an entry in the
palette, but this doesnt seem to be true...

Am i missing something.?

Thanks


-- 
Fabrice Gautier, 
####@####.####

Fabrice Gautier wrote:
> When i display images, nano-X seems to modify the palette, but it doesnt
> seem to be good at it.

Yes, the simple algorithm it uses is terrible, and it doesn't force a 
redraw either after it messes with the palette. The symptom I was seeing 
was that displaying an image with a lot of colours "stole" a lot of the 
colours which other things on the screen were already using, and then it 
doesn't even force a redraw so all the colours are messed up until you 
wave a window around the screen forcing it to redraw everything. I got 
much better results simply fixing the palette so the colours never get 
automatically redefined.

> I would like to have a fixed palette, that only the user changes, how can i
> do that?

In my tree you can change FIXEDPALETTE to 1 in device.h to disable the 
dynamic palette stuff (actually I think I left that as default). You 
should be able to set the palette yourself with GrSetSystemPalette().

http://www.linuxhacker.org/pub/cvs-snapshots/microwin-aph/

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

: Yes, the simple algorithm it uses is terrible, and it doesn't force a 
: redraw either after it messes with the palette. The symptom I was seeing 
: was that displaying an image with a lot of colours "stole" a lot of the 
: colours which other things on the screen were already using, 

The current algorithm was designed so that a single complex
image could be displayed using the exact colors it requested.
When multiple images are displayed, the algorithm doesn't do
too well.  Looking at the code in engine/devdraw.c, there's a 
global gr_firstuserpalentry.  This is normally set a value that divides
the programmer-supplied palette into two: values below this value
will be used for all system-shared images, borders, title bars, etc.
Values above will be used to custom-allocate colors when 
an image requests it.  By default, a three-part palette is
supplied: engine/devpal8.c.  The first 16 colors are std EGA
colors.  The second 32 are basic windows colors.  The final
216 colors are a uniform palette, used to display most images
in a basic fashion.  To turn off any palette optimization for
images, just set gr_firstuserpalentry to 256.

The reason Microwindows doesn't force a redraw when
values above gr_firstuserpalentry are first used is that it doesn't
track palette multiple uses of palette entries.  I originally decided
to keep the color model simple.  To correct this, instead of
merely using entries above a marker, each palette entry needs
to be assigned a use count, and this needs to be tracked per
application.

Regards,

Greg




and then it 
: doesn't even force a redraw so all the colours are messed up until you 
: wave a window around the screen forcing it to redraw everything. I got 
: much better results simply fixing the palette so the colours never get 
: automatically redefined.
: 
: > I would like to have a fixed palette, that only the user changes, how can i
: > do that?
: 
: In my tree you can change FIXEDPALETTE to 1 in device.h to disable the 
: dynamic palette stuff (actually I think I left that as default). You 
: should be able to set the palette yourself with GrSetSystemPalette().
: 
: http://www.linuxhacker.org/pub/cvs-snapshots/microwin-aph/
: 
: -- 
: ------------ Alex Holden - http://www.linuxhacker.org ------------
: If it doesn't work, you're not hitting it with a big enough hammer
: 
: 
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
: