[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
GetPalette mods to Nano-X
From: Greg Haerr ####@####.#### Date: 29 Nov 1999 18:46:59 -0000 Message-Id: <796896539E6CD311B0E70060083DFEFB076B2B@NBA-SLAM.CenSoft.COM> Richard, I'm trying to finish the design of the getpalette functionality that you need for the opera browser for Nano-X. I've been waiting until I got the new client/server design completed before starting. In the new design, each request and/or reply contains a message size field that allows replys to be variable-length, rather than fixed length limitations in the past. Because of this, GrGetSystemPalette can now return a variable length palette, rather than a fixed, say 256 size one. Currently, I'm thinking of the following api: GrGetSystemPalette(int first,int count,GR_PALETTE *pal); typedef struct { int first; int count; RGBENTRY rgb[]; } GR_PALETTE; That is, GrGetSystemPalette would return just the portion of the system palette that is asked for, with RGB values for each index. The size of the palette can be known through the SCREENINFO struct, returned by GrGetScreenInfo. In addition, I think we need the call PIXELVAL GrFindNearestColor(COLORVAL c) which returns the pixel value of the nearest color to the RGB colorval passed, using the current system palette. In truecolor modes, it returns a 5/6/5 or 3/3/2 or 8/8/8 value. Will these two functions solve your needs? I would rather not add a SetPalette function, instead letting the system map colors from a fixed palette. Otherwise we will need to bring in the concept of colormaps and/or virtual palettes, and I'd like to avoid that complexity for now. Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |