lør, 19.04.2003 kl. 13.18 skrev Ann and Jason Edmeades:
So if windows would not generate WM_QUERYNEWPALETTE inside RealizePalette for >256 colours?
You mean WM_PALETTECHANGED inside RealizePalette? WM_QUERYNEWPALETTE is sent on window activation.
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;
- Dont do updating of the mapping for truecolour? Put the code at the top of X11DRV_RealizePalette so we skip the rest
- Do the mapping but fake a zero return code? Put the code at the bottom of X11DRV_RealizePalette
I'd expect windows to use what's behind door number 1 (there's no mapping to update, GDI operations should map palette indices straight to truecolor using the DC's logical palette (set with SelectPalette), not through the system palette (changed by RealizePalette)), but it's been too long since I looked at this code for me to say whether Wine is able to do the same right now. It probably can, but the only way to be sure is to either check the code or test with some programs that do use the palette in various ways even in truecolor mode.