On 20 May 2014 13:09, Stefan Dösinger stefan@codeweavers.com wrote:
This function is a bit silly. I think all callers should be able to just use palette->colors[], and avoid the extra copy. I'd guess that if no palette is set on the swapchain it should use the system palette, but perhaps it's ok to leave that undefined for now.
This is problematic in wined3d, because you can have multiple swapchains using the same palette. In practice that never happens, but that depends on knowing about everything that calls wined3d. If you really need this kind of scheme you'd have to make "palette->changed" a counter, and then iterate over all swapchains on wrap, but couldn't you just create a GDI palette for the wined3d palette, and then select that into the DC for the blit? Or just always update the palette, which is pretty much what we do now in the GL case.
Am 20.05.2014 um 14:27 schrieb Henri Verbeet hverbeet@gmail.com:
Yes, except for setting color[i].alpha = i. This should eventually be handled by the caller, and in the case of the ARB blitter, the shader. That’s a topic for a different patch though.
Yes, but it’s not as easy as as calling GetSytemPaletteEntries because we’re not actually in P8 mode. I think the best we can do is create a wined3d default palette that contains the fixed entries of the Windows system palette and sets the other colors to black / white / pink whatever. If there's an application that modifies the system palette via gdi and then uses ddraw with an undefined palette we'll need a more elaborate paletteindexed mode emulation scheme that probably involves winex11.drv/winemac.drv.
A previous (unsent) version kept the flag in the swapchain and iterated over all attached swapchains similar to what swapchain_realize_palette was doing. That would handle multiple swapchains, but I'd prefer to keep it in the palette because eventually the palette should maintain the P8 blit texture and will need the dirty flag for this purpose.
I'm not entirely sure what the relation between the DIB color table and the device context's palette is. I read plenty of documentation and experimented with this on Windows when I wrote the getdc palette tests. I couldn't make the HPALETTE attached to a DC from a surface do anything on Windows. I'll see if it magically does something in x11_copy_to_screen.
Or just always update the palette, which is pretty much what we do now in the GL case.
Sure, that's always a fallback option, but I'd prefer to avoid it.
On 20 May 2014 16:35, Stefan Dösinger stefandoesinger@gmail.com wrote:
Yes, except for setting color[i].alpha = i. This should eventually be handled by the caller, and in the case of the ARB blitter, the shader. That’s a topic for a different patch though.
I don't think we need that since afaik we should never do RGBA -> P8 blits / presents. But even then, does this even work for swapchain surfaces? I'd expect the alpha channel to just be lost.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-05-20 17:17, schrieb Henri Verbeet:
I'm not sure what you mean with RGBA -> P8 blits. Those never worked, and I don't expect them to do anything reasonable on Windows.
But still I think you're right and it is safe to remove this code. What we needed this for is reading back P8 drawables that were converted to RGBA, and since 7b049245 that's only the front buffer. If the conversion is done with the shader we have the unmodified ALPHA8 texture. Otherwise we set SFLAG_CONVERTED and never free sysmem and don't do GL-side blits. (Ddraw will never read back the front buffer, but wined3d doesn't know that.)
Re GDI presents: A HPALETTE attached to the device context doesn't do anything, as expected. If I understand GDI palette handling correctly, the attached palette only matters when drawing to a device context that has a palette-indexed bitmap / window attached, but not when reading from it. The DIB color table determines the color values produced when reading from a palette-indexed DIB section.
-
Henri Verbeet -
Stefan Dösinger