Increase precision in linear_to_srgb() and srgb_to_linear()
#100659
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This avoids the situation where white stops being white after conversion. While maintaining as much floating point ops as possible
clayjohn
added
bug
topic:core
regression
cherrypick:4.3
akien-mga
approved these changes
Dec 20, 2024
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #100517
This was a combined regression from #93802 and #57703
#57703 forced most color functions to use floating point operations which is nice for performance and generally makes sense. However, in this specific case, double precision is needed.
This PR removes the float literal qualifiers from just enough places to allow the compiler to make a smart decision about how much to keep in floating point and how much to do with doubles. In theory this will be slightly slower, but we have no choice.
The regression became apparent after #93802 because the canvas modulate color is always 1 by default and converting it to linear (which is needed when using a linear viewport) turns it into 0.99999988. Which, when applied over many frames by ping-ponging the buffer, results in a darkening of the viewport. Presumably every other place where these functions are called is tolerant of this slight precision error.
I added tests to ensure that we don't accidentally make the same mistake again. This is a case where
is_equal_approx()has too high of a tolerance and we need to use exact floating point comparison with==.