[akx]

Follows up on #7589. I noticed this looking at pytest --durations; a fuzzer test that just loads a DDS was surprisingly slow, and turns out doing 1-byte reads is not very efficient...

Locally:

$ pytest-benchmark compare --between=min .benchmarks/Darwin-CPython-3.14-64bit/*.json
Name (time in us)                   0001_orig Min  0002_new Min      ΔMin
-------------------------------------------------------------------------
test_load[uncompressed_rgb.dds]      405,475.7920    1,589.0000    -99.6%
-------------------------------------------------------------------------

or 255.17 times lower minimum, or in average OPS terms, +22351.7% faster. 😂

[radarhere]

As far as uncompressed_rgb.dds is concerned, I think I can do you one better. #7589 added DdsRgbDecoder in order to generalise this decoding path, but before that, this file was read with the raw decoder.

So if apply the following change to main to use the raw decoder for this specific scenario, you will find it faster than the current state of this PR.

diff --git a/src/PIL/DdsImagePlugin.py b/src/PIL/DdsImagePlugin.py
index 40012bc27..a6cec0557 100644
--- a/src/PIL/DdsImagePlugin.py
+++ b/src/PIL/DdsImagePlugin.py
@@ -371,8 +371,11 @@ class DdsImageFile(ImageFile.ImageFile):
                 mask_count = 3
 
             masks = struct.unpack(f"<{mask_count}I", header[84 : 84 + mask_count * 4])
-            self.tile = [ImageFile._Tile("dds_rgb", extents, 0, (bitcount, masks))]
-            return
+            if masks == (0xFF0000, 0x00FF00, 0x0000FF):
+                rawmode = "BGR"
+            else:
+                self.tile = [ImageFile._Tile("dds_rgb", extents, 0, (bitcount, masks))]
+                return
         elif pfflags & DDPF.LUMINANCE:
             if bitcount == 8:
                 self._mode = "L"

[akx]

@radarhere Good stuff! 🎉 Applied that on here too. I checked pytest-cov, and with that applied the speedups from dadbf4f are still tested and used, so this is a double win :)

[akx]

This would probably be nice to merge for testing/DX's sake as well.

Looks like PyPy is hit hard by this and it spends ~22% of the entire test run time on uncompressed_rgb.dds tests:

23.18s call     Tests/test_file_dds.py::test_uncompressed[RGBA-size4-Tests/images/uncompressed_rgb.dds]
22.96s call     Tests/oss-fuzz/test_fuzzers.py::test_fuzz_images[Tests/images/uncompressed_rgb.dds]

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 2 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 668 untouched benchmarks
⏩ 352 skipped benchmarks¹

---

_{Comparing akx:dds-speedup (cda38df) with main (842928a)}

Footnotes

1. 352 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[radarhere]

What was your thinking here? It would have previously been 'ValueError: not enough image data'. So you wanted to clarify?

No good faith image should ever trigger this, so I'm not too concerned.

[akx]

Yep. The test needed changing for the new "Truncated File Read" error message, and once I did that, the test failed for that one file where we reached this path... so it was more obvious to just raise with a specific error here and catch that in the test.