Repository navigation
Fix Color.hex ignoring the conversion failure and not clamping components - #891
Merged
Merged
Conversation
…ents `hex` discarded the result of `getRed(_:green:blue:alpha:)` and formatted the zero-initialized components, so every color with no sRGB representation - pattern colors on both platforms - hexed to `"#00000000"` and shared an identifier with `.clear` and with each other. Two distinct border colors could therefore be served each other's processed bytes from the disk cache while the memory cache, which hashes the color object, kept them apart. The components were also formatted unclamped. A P3 color converts to extended sRGB with components outside of `0...1`, which produced malformed hex on iOS, e.g. `"#117FFFFFFFFFFFFFFC6FFFFFFFFFFFFFFDA"` for P3 red. `hex` is now optional and the components are clamped to `0...1`. `Border.description`, which feeds the identifiers of the processors that draw borders, falls back to the color's own description so that the colors with no hex stay distinct instead of collapsing onto one value.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Two problems in
Color.hex, which feedsBorder.descriptionand through it the identifiers ofCircleandRoundedCorners:The result of
getRed(_:green:blue:alpha:)was discarded. It returnsfalsefor the colors with no RGB representation — pattern colors — leaving the zero-initialized components in place, so all of them hexed to"#00000000"and shared an identifier with.clearand with each other. Two distinct border colors could be served each other's processed bytes from the disk cache, while the memory cache, which hashes the color object, kept them apart.The components were formatted unclamped. A P3 color converts to extended sRGB with components outside of
0...1, soString(format: "%02lX", lroundf(1.093 * 255))produced"117"and the negative components produced"FFFFFFFFFFFFFFC6". P3 red hexed to"#117FFFFFFFFFFFFFFC6FFFFFFFFFFFFFFDA"on iOS.hexis now optional and returnsnilwhen the color has no sRGB representation, and the components are clamped to0...1.Border.descriptionfalls back to the color's own description so that such colors stay distinct from one another instead of collapsing onto a single, already-taken value.