On Mon Sep 29 21:59:33 2025 +0000, Matteo Bruni wrote:
If I understand correctly, this affects the output. In which case I'd avoid calling it an optimization, both in the comment and the commit subject. It's a bit of a pet peeve of mine, please bear with me...
I wrote this patch awhile ago, I _think_ I used the term optimization to bolster my argument for changing this behavior. It technically should be faster as it lets us get out of this function earlier. The decompressed values don't change with this "optimization".
The actual compressed data values shouldn't really matter, what should matter is the decompressed values. But, in `check_texture{2d,3d}_data()`, we check for compressed values. What would be a better term to use here? Just "Wine specific change"?