Clamp gradient color opacity #1636
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
AlexKGwyn
commented
Oct 1, 2020
| @@ -139,7 +139,7 @@ private int getOpacityAtPosition(double position, double[] positions, double[] o | |||
| double lastPosition = positions[i - 1]; | |||
| double thisPosition = positions[i]; | |||
| if (positions[i] >= position) { | |||
| double progress = (position - lastPosition) / (thisPosition - lastPosition); | |||
| double progress = MiscUtils.clamp((position - lastPosition) / (thisPosition - lastPosition), 0, 1); | |||
There was a problem hiding this comment.
I assume it would be fine to change the precision of the progress and use an existing clamp method. I didn't want to make that change without some more knowledge about the choices here though.
|
@AlexKGwyn This looks great. I verified that the diffs in the link above are, in fact, more accurate that the originals. Could you also add your json file to this folder. That will automatically include it in the report above. |
gpeal
pushed a commit
that referenced
this pull request
Oct 4, 2020
Fixes an issue where color positions that came before any opacity positions in a gradient color array were interpolated to negative values, throwing off the conversion into a color.
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 an issue where color positions that came before any opacity positions in a gradient color array were interpolated to negative values, throwing off the conversion into a color.
An example of a gradient color array that presented this issue:
"k": [0, 0.969, 0.514, 0.745, 0.116, 0.984, 0.537, 0.373, 1, 1, 0.559, 0, 0.607, 0, 0.776, 0.5, 0.945, 1]
Colors
0, 0.969, 0.514, 0.745,
0.116, 0.984, 0.537, 0.373,
1, 1, 0.559, 0,
Opacity
0.607, 0,
0.776, 0.5,
0.945, 1
Since the first color came before the first opacity position, the progress was calculated as about -3.59 causing the following linear interpolation to give out a large negative value which broke things when it was bit shifted into the alpha position for the final color.
Here are some screenshots:
Original issue
Resolved
Sample Json (as a txt because github doesn't allow json)
testjson.txt