[PATCH 1/3] windowscodecs/tests: In the tests of DdsDecoder_Initialize(), use broken() for cube map and uncompressed DDS image.
Loading cube map or uncompressed DDS image will fail on navtive WIC. But we would like to support them in our builtin implementation.
Signed-off-by: Ziqing Hui zhui@codeweavers.com --- dlls/windowscodecs/tests/ddsformat.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
I don't like the idea of returning success when native would fail and relying on this in other parts of Wine. It's possible that an application depends on these image types failing, and we wouldn't be able to fix that application without breaking d3dx10.
We can add our own components that are different from native, like the existing ICNS and TGA format support. One possibility would be to have two CLSIDs for our DDS decoder. It could behave the same as native when invoked with CLSID_WICDdsDecoder, and accept these files when invoked with CLSID_WineDdsDecoder. We could then use CLSID_WineDdsDecoder in other parts of Wine.
Wine-specific COM interfaces could also work.
I think you are right, it would be better to have some Wine-specific stuff.
Uncompressed DDS and cube map will fail on DdsDecoder_Initialize().
What about introduce a Wine-specific COM interface called WineDdsInitializer which has only one function WineDdsInitializer_Initialize() that won't fail for uncompressed DDS and cube map. I think this is the simplest solution for the situation here. What do you think?
On 7/9/20 12:11 AM, Esme Povirk (they/them) wrote:
I don't like the idea of returning success when native would fail and relying on this in other parts of Wine. It's possible that an application depends on these image types failing, and we wouldn't be able to fix that application without breaking d3dx10.
We can add our own components that are different from native, like the existing ICNS and TGA format support. One possibility would be to have two CLSIDs for our DDS decoder. It could behave the same as native when invoked with CLSID_WICDdsDecoder, and accept these files when invoked with CLSID_WineDdsDecoder. We could then use CLSID_WineDdsDecoder in other parts of Wine.
Wine-specific COM interfaces could also work.
What about introduce a Wine-specific COM interface called WineDdsInitializer which has only one function WineDdsInitializer_Initialize() that won't fail for uncompressed DDS and cube map. I think this is the simplest solution for the situation here. What do you think?
Sure, that would work.
-
Esme Povirk (they/them) -
Ziqing Hui