[Joel Kiptoo (Kiptoo-Deus)]

Fixes #350.

FlipRotate was the only image operation that always used WIC, so DirectXTexFlipRotate.cpp was only built on Windows and the functions were declared under #ifdef _WIN32.

This builds it on all platforms. On Windows nothing changes: the WIC path and the float16/float32 conversion path are the same code, now inside #ifdef _WIN32. On other platforms, a new PerformFlipRotate moves whole pixels directly:

• Supported: formats that are not compressed, packed, planar or palettized and have a whole number of bytes per pixel (8 to 128 bits). Other formats return HRESULT_E_NOT_SUPPORTED, checked before the result is allocated.
• Rows are copied with a single memcpy when there's no horizontal flip and no 90/270 rotation.
• Combining a rotation with a flip: the WIC documentation doesn't say which is applied first. I followed Wine's IWICBitmapFlipRotator (dlls/windowscodecs/fliprotate.c), where the flip is applied to the source before the rotation (e.g. TEX_FR_ROTATE90 | TEX_FR_FLIP_HORIZONTAL is an anti-transpose). I couldn't check this against WIC itself, so it would be worth confirming on Windows. It only matters for a 90/270 rotation combined with exactly one flip.

Testing on macOS (arm64, Apple clang), building DirectXTex with its own CMake against the vcpkg directx-headers and directxmath ports:

• The library builds with DirectXTexFlipRotate.cpp included, with no new warnings.
• A test compares both FlipRotate overloads against a straightforward reference (flip the source, then rotate clockwise in 90 degree steps) for every rotation/flip combination, on a 7x5 image with 3 array slices, in R8_UNORM, R16_UNORM, R8G8B8A8_UNORM, R16G16B16A16_FLOAT, R32G32B32_FLOAT and R32G32B32A32_UINT (1 to 16 bytes per pixel). It also checks that BC1_UNORM, NV12, YUY2, R1_UNORM, P8 and R8G8_B8G8_UNORM return HRESULT_E_NOT_SUPPORTED, and that null pixels return E_POINTER. 187 checks pass.
• Making the reference rotate first and flip second fails exactly the 48 cases combining a 90/270 rotation with a single flip, so the test does pin down the order.

I haven't built the Windows configurations. The only change there is the added #ifdef _WIN32 guards around the existing code.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Joel Kiptoo (Kiptoo-Deus)]

Got access to a Windows machine and tested the flip/rotate order against WIC. It matches. I compared the WIC output with the new non-WIC path byte for byte across a bunch of formats, every rotation/flip combination, and both overloads, with no differences. I also flipped the order in my reference to make sure the test would catch it, and that fails on the 90/270 + single flip cases as expected. So WIC does flip first, same as Wine.

The library also builds cleanly on MSVC x64 with the new #ifdefs.

[Chuck Walbourn (walbourn)]

The arm64ec failures are a new 'known issue' thing. Don't worry about them.

This is great, but to be consistent the non-WIC path should be available on Windows as well, which will make it easier to add it to the test coverage as well.

You should code it to use your non-WIC version on (a) Linux where WIC is not available and (b) on Windows if you pass a flag telling it to use non-wic paths. Something like: TEX_FR_FORCE_NON_WIC = 0x1000

[Joel Kiptoo (Kiptoo-Deus)]

Done, added TEX_FR_FORCE_NON_WIC (0x1000). On Windows it makes both FlipRotate overloads use the non-WIC code; on Linux/macOS it doesn't change anything since that's the only path there. Passing just the flag on its own still gives E_INVALIDARG.

I ran it on my Windows PC, comparing WIC against the forced non-WIC path across a handful of formats, every rotate/flip combo, with and without mips. Output was identical in every case.