Hi Ove, Thanks for the kind help - I was just diving into the
palette code to try to work out how it worked!
>Do you actually run Windows in a 256-color mode? If not, then Windows
>does not have a need for messing with a system palette, so it neither
>honors realization requests nor does it send any palette messages (not
>even WM_QUERYNEWPALETTE, which wine always sent last time I checked).
That was what interested me from Alexanders update - I run my windows
system in 16 bit and my Linux system in 24 bit color, so I was even
more suprised that the palette needed playing with.
So if windows would not generate WM_QUERYNEWPALETTE inside RealizePalette
for >256 colours? Looking through the code I think it is 'easier' to
do it inside palette.c since we maintain a flag, X11DRV_PALETTE_VIRTUAL
for true colour, otherwise we need to look it up each time.
I have 2 complete guesses af a fix, any thoughts as to which is more
appropriate? (As they both work for me but could easily break something!)
/* For X11DRV_PALETTE_VIRTUAL (>256 colours), no need to realize */
if( X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL )) return 0;
1. Dont do updating of the mapping for truecolour?
Put the code at the top of X11DRV_RealizePalette so we skip the rest
2. Do the mapping but fake a zero return code?
Put the code at the bottom of X11DRV_RealizePalette
Any thoughts which is better?
(My current patch which I will run with for now is attached)
Thanks!
Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: palettefix.20030419.patch
Type: application/octet-stream
Size: 682 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030419/ab41d8be/palettefix.20030419.obj