Palettes - Any experts?

[Ann and Jason Edmeades]

Hello, Having taken a break for a few months I thought I'd try playing with
wine again...

I have been trying to work out why one game I am investigating never even
shows its splash screen, and have got most of the way until I have got
stuck. Can anyone offer me some advice?

The game launcher kicks off a process whose first thread creates a dummy
16x16 window which is placed in the center of the screen (who knows why!),
and launches another thread. The main thread then proceeds to create another
process, and wait for it to complete. This means the dummy window is not
processing any messages and if sent any the whole thing hangs :-(

The launched thread creates the splash screen and begins a WM_PAINT
operation. During this processing it calls CreateCompatibleDC, SelectObject,
SelectPalette and finally RealizePalette

This RealizePalette call (UserRealizePalette, windows\painting.c) results in
256 colors being mapped in, and SendMessageA( HWND_BROADCAST,
WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs
attempting to send the message to the first thread as it is in a hung state
waiting for another process to end. Under windows, the RealizePalette
returns 0, and spy on Windows does not show this message being sent to the
'hung' thread.

'Interestingly', putting an xterm behind the splash panel, and trying to
bring it to the front (to force a repaint) shows that UserRealizePalette is
always returning 256, which I thing is the underlying bug. It appears to
create a palette every WM_PAINT operation.

Commenting out the broadcast makes the splashscreen appear perfectly, so I
know I am along the right lines.

Can anyone fill in some gaps and point me in the right direction? Debug logs
willingly available! :-)

Thanks
Jason

[Alexandre Julliard]

"Ann and Jason Edmeades"  writes:
> This RealizePalette call (UserRealizePalette, windows\painting.c) results in
> 256 colors being mapped in, and SendMessageA( HWND_BROADCAST,
> WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs
> attempting to send the message to the first thread as it is in a hung state
> waiting for another process to end. Under windows, the RealizePalette
> returns 0, and spy on Windows does not show this message being sent to the
> 'hung' thread.

The message should probably be sent with SendMessageTimeout with the
SMTO_ABORTIFHUNG flag. The only problem is that this flag is not
implemented yet...

[Ann and Jason Edmeades]

> > This RealizePalette call (UserRealizePalette, windows\painting.c) results

in
> > 256 colors being mapped in, and SendMessageA( HWND_BROADCAST,
> > WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs
> > attempting to send the message to the first thread as it is in a hung

state
> > waiting for another process to end. Under windows, the RealizePalette
> > returns 0, and spy on Windows does not show this message being sent to

the
> > 'hung' thread.
> The message should probably be sent with SendMessageTimeout with the
> SMTO_ABORTIFHUNG flag. The only problem is that this flag is not
> implemented yet...

Prossibly, and let me guess.. "if the receiving process appears to be in a
"hung" state"
is difficult to determine? (Otherwise, I guess it isnt that difficult to
implement
as the rest of it is all there).

The only reason I hesitate to agree with you is the difference in the
RealizePalette
returns, one (wine) indicating 256 colors had to be changed, the other
(win2k)
indicating none had to be.  Maybe this is a side effect of our x11drv
palette
implementation, but it still is slightly worrying?

Whats the best way to progress this? I can continue plodding by commenting
out the
whole line, so shall I just raise a bug for it?

Jason

[Alexandre Julliard]

"Ann and Jason Edmeades"  writes:
> The only reason I hesitate to agree with you is the difference in
> the RealizePalette returns, one (wine) indicating 256 colors had to
> be changed, the other (win2k) indicating none had to be.  Maybe this
> is a side effect of our x11drv palette implementation, but it still
> is slightly worrying?

There are quite likely many other problems in the palette code, there
has been very little attention devoted to that code lately since just
about everybody uses true color displays now. So if there are
differences with Windows it's probably safe to assume that it's a bug
in the palette code.

[Ove Kaaven]

tir, 15.04.2003 kl. 20.23 skrev Ann and Jason Edmeades:
> > > This RealizePalette call (UserRealizePalette, windows\painting.c) results
>
> in
> > > 256 colors being mapped in, and SendMessageA( HWND_BROADCAST,
> > > WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs
> > > attempting to send the message to the first thread as it is in a hung
>
> state
> > > waiting for another process to end. Under windows, the RealizePalette
> > > returns 0, and spy on Windows does not show this message being sent to
>
> the
> > > 'hung' thread.
> > The message should probably be sent with SendMessageTimeout with the
> > SMTO_ABORTIFHUNG flag. The only problem is that this flag is not
> > implemented yet...
>
> Prossibly, and let me guess.. "if the receiving process appears to be in a
> "hung" state"
> is difficult to determine? (Otherwise, I guess it isnt that difficult to
> implement
> as the rest of it is all there).
>
> The only reason I hesitate to agree with you is the difference in the
> RealizePalette
> returns, one (wine) indicating 256 colors had to be changed, the other
> (win2k)
> indicating none had to be.  Maybe this is a side effect of our x11drv
> palette
> implementation, but it still is slightly worrying?

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).

[Ann and Jason Edmeades]

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

[Ove Kaaven]

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.