On Thu Oct 24 23:36:21 2024 +0000, Matteo Bruni wrote:
Okay, now for a more architectural point... I'm not particularly keen about making use of WIC conversion stuff. Among other things, d3dx9 has flags to control filtering and such and those don't really map to WIC's. Currently we don't implement most of them, to be fair, but using WIC doesn't seem like a move in the right direction. Could we reasonably use the existing d3dx9 machinery (`d3dx_load_pixels_from_pixels()` and such) to convert the image to the desired format? Are we going to get problematic formats out of WIC, or is there some other issue that makes that complicated? For the two relevant formats in this MR, I expect the 24 -> 32 bpp conversion to already work. The 48 -> 64 bpp one is tricky because we'd need a new `formats[]` entry and there is no suitable `D3DFORMAT` for a 3 channel 16 bpc UNORM format. But that's basically a self-imposed limitation, nothing forces us to use `D3DFORMAT` to identify formats internally. Looking at your branches, I see that you end up with an `enum d3dx_pixel_format_id` to identify formats in d3dx, which should indirectly fix this. I'd suggest to simply defer converting from those "unrepresentable" formats (or maybe this whole conversion business entirely) to some time after `enum d3dx_pixel_format_id` is introduced, unless you really need it sooner.
Yeah the 48->64bpp one is the trickier one, but ultimately solvable with `enum d3dx_pixel_format_id` patches. I can defer handling these until that stuff is upstream if that's preferable.
I kind of intended on this to be a stop gap to solve some of the test todos in my surface to file saving patches. Once those were upstream, we could replace this with d3dx conversions instead. Or, I guess I could just do the `enum d3dx_pixel_format_id` patches prior to introducing the new saving code. My main concern with that is introducing an internal format ID seemed like it should be included with code sharing with d3dx10, which is why I initially moved to it. But, I guess having an image with a format that isn't represented by the existing `D3DFORMAT` IDs is also a motivation to introduce `enum d3dx_pixel_format_id` early.