>> 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?