[PATCH 1/3] windowscodecs/tests: In the tests of DdsDecoder_Initialize(), use broken() for cube map and uncompressed DDS image.

[Ziqing Hui]

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(a)codeweavers.com>
---
 dlls/windowscodecs/tests/ddsformat.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

[Esme Povirk (they/them)]

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.

[Ziqing Hui]

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.

[Esme Povirk (they/them)]

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