[PATCH] windowscodecs: Add support for DIB format.

[Vincent Povirk]

>> If there's really a demand for using native windowscodecs without
>> breaking d3dx9 (which already happens because of the TGA decoder), I
>> can supply a win32 build of our WIC extensions that winetricks could
>> install with it. I can't do anything about ICNS.
>
> TGA is the simplest format I've ever seen, CreateBitmapFromMemory is
> the straight way to handle it. I haven't looked at ICNS support, but
> probably it could be implemented using public APIs as well.

The main reason I put the TGA decoder in WIC is that I know nothing
about d3dx9 and wanted to help solve the problem without having to
learn a new codebase. I don't know enough about d3dx9 to say whether
it makes sense to put new image format handling code in there (other
than DDS, which has features WIC can't support), but I can't imagine
it making sense to move an existing, working format there.

>> Sure, but we ALREADY HAVE CODE for packed dibs that was essentially
>> free and that is currently maintained. To do this from GDI, we still
>> have to write code in d3dx9 that parses the packed DIB enough that we
>> can pass it so some GDI function, then write code that converts a GDI
>> bitmap to a D3DX surface. It gets a little more complicated when you
>> consider things like palettes and rle encoding.
>
> DIB sections and things like SetDIBits should take care of all of this.

SetDIBits still requires us to calculate the offset of the bitmap
bits, which requires understanding of the format. Which we would have
to duplicate between WIC and D3DX, because we already need that logic
in the WIC ICO decoder. And it definitely does not give us any usable
D3DX structures without further work.

These aren't very hard problems, sure, but I can't see the
justification for writing new solutions to any problems when we
already have something that should work with no extra effort.

>> So now we need code in WIC that copies ICO streams into a file on disk
>> so we can get an HICON for the bitmap frames (they could all be PNG)
>> so we can pass that to CreateBitmapFromHICON? No thanks.
>
> I don't see why you need to write anything to a file at all for a decoder
> if you already have bitmap bits.

Writing to a file is the only way I can see to make the standard icon
handling functions (ExtractIcon) handle the format. If we don't use
those, we have to handle the quirks of masks and double heights, at
which point GDI doesn't help us very much.

Maybe if we were starting from scratch it would've made sense to solve
these problems differently. Obviously I disagree or I wouldn't have
done things the way I did. But the ICO/BMP decoder we have now works
(and probably works for DIB as well) and has no known problems that we
can't solve with the current design. Why would we want to tear it down
and replace it with three new things, or even just add one new thing
to d3dx to handle a case the decoder can handle now?