RE: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Stefan Dösinger]

Actually, one more idea:

It will be extra-slow, but we could implement a general all-to-all format by converting the source format to A32R32G32B32F(float values), and then write code to convert this format to all possible destination formats. The from->to table lookup could be replaced by code that can combine multiple conversions to find a conversion strategy(e.g. R5G6B5->ARGB32F->R8G8B8). I am not sure if it is a good idea, but it is worth a consideration

wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Victor]

On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> Actually, one more idea:
>
> It will be extra-slow, but we could implement a general all-to-all format
> by converting the source format to A32R32G32B32F(float values), and then
> write code to convert this format to all possible destination formats. The
> from->to table lookup could be replaced by code that can combine multiple
> conversions to find a conversion strategy(e.g. R5G6B5->ARGB32F->R8G8B8). I
> am not sure if it is a good idea, but it is worth a consideration

I thought about that, but decided that it'll be too slow (conversion to float 
and back), and there are more than 4 possible channels (luminance, palette, 
depth, stencil, channels for formats like D3DFMT_V8U8), there are compressed 
formats like DXT, and two palette formats that would need additional data for 
conversion. I think it makes sense (later) to implement several different 
generic converters, several special conversion functions (like A8R8G8B8->P8) 
and then use this strategy to combine all these converters into one chain. It 
makes sense to consider which conversions are really used. Stuff like 
R5G6B5->X8R8G8B8 is common, but I don't think anyone would ever need 
D24S8->ARGB32F. Even ARGB32F->P8 is unlikely (although X8R8G8B8->P8 is 
required by some games).

On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> The patch looks reasonably, just one small thing: There is a count_bits
> function implemented in utils.c, which as far as I can see does the same as
> getMaskSize. Can you check if you can reuse it?

Done and resubmitted (count_bits was more elegant, by the way). But I hope 
that there is a warranty that unsigned int isn't less than 32 bit on all 
systems where WINE is used (maybe I'm just paranoid).