On Tue Sep 30 10:49:33 2025 +0000, Connor McAdams wrote:
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"?
So, in general I'd expect a change described as "optimization" to only affect performance, not output values. There are cases where there isn't this kind of expectation (e.g. compiler optimization settings will change generated code, although that in turn shouldn't usually behave differently) and, as things are, I don't think this one is much of an abuse of the term "optimization".
Still, I do slightly prefer "change", as you mentioned, or something similar (tweak?)