-
-
Notifications
You must be signed in to change notification settings - Fork 852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradient Brushes #542
Gradient Brushes #542
Conversation
d284b76
to
bc6e35c
Compare
…ush, not yet working - what's wrong?
bc6e35c
to
c02f9d8
Compare
|
||
private readonly Point end; | ||
|
||
private readonly Tuple<float, TPixel>[] colorStops; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to define a small private struct instead of Tuple<float, TPixel>
. It provides:
- Better readability
- Better memory locality (
Tuple<>
-s are classes on the heap)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point. Thanks. Except that the struct can't be private as it's used as a parameter in the Brush constructor. Therefore I'll use a public nested struct instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason you are getting a black screen is because of a bug in the base Apply
method.
the test if (this.Options.BlendPercentage < 1)
is incorrect and instead should read if (this.Options.BlendPercentage <= 1)
i.e. less than or equal to instead of less than
Assert.Equal(Rgba32.Red, sourcePixels[0, 0]); | ||
Assert.Equal(Rgba32.Red, sourcePixels[9, 9]); | ||
Assert.Equal(Rgba32.Red, sourcePixels[199, 149]); | ||
Assert.Equal(Rgba32.Red, sourcePixels[500, 500]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this need to be 499
not 500
as its one pixel wider than the buffer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, you're right. fixed.
I've renamed the PR, we will happily keep reviewing it as you make improvements, once your fully happy and want a final review/merge just update the title again and drop the |
thanks @tocsoft for investigation and finding the bug. He proposed to just replace < by <= in line 78, but that would only shift the problem to values > 1. Those values should not be used from a semantic point, but it's not forbidden in a float value. My fix here keeps the <, but adds an else path that uses the original value from scanline[i]. This adds an else to the code (which technically adds a jump after the then-part), but omits the multiplication. The simple solution @tocsoft proposed might be faster, but should be preferred if and only if BlendPercentage can be guaranteed to be <=1.
as proposed by @antonfirsov: improving readability and memory locality.
Codecov Report
@@ Coverage Diff @@
## master #542 +/- ##
==========================================
- Coverage 87.67% 87.26% -0.41%
==========================================
Files 838 840 +2
Lines 34684 35107 +423
Branches 2533 2553 +20
==========================================
+ Hits 30410 30637 +227
- Misses 3524 3719 +195
- Partials 750 751 +1
Continue to review full report at Codecov.
|
test images don't have to be that big for axial gradients. It's sufficient to show they're constant across the axis and correct along the axis.
the theory lacks color checks yet that should be added, but it produces output images for visual control
somehow these don't look correct yet, containing hard edges sometimes.
@antonfirsov thanks for the changes. I still have 71 failing tests locally. On the first sight those are the same we thought to fail due the Vector2 issue, and: the same tests fail on SixLabors/master, too here. So I'm fine with merging the branch. |
Everything looks good now @jongleur1983's local test running issues are unrelated to his PR. I'm planning to merge this soon, let me know if there are blocker issues we've missed, so I shouldn't! |
/// Base class for Gradient brushes | ||
/// </summary> | ||
/// <typeparam name="TPixel">The pixel format</typeparam> | ||
public abstract class AbstractGradientBrush<TPixel> : IBrush<TPixel> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, one naming question mostly to @JimBobSquarePants :
Shouldn't we name this GradientBrushBase
or simply GradientBrush
to match our current naming patterns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this should be GradientBrushBase
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done (and renamed the BrushApplicator as well)
Finally merged! |
as proposed by @antonfirsov: improving readability and memory locality.
test images don't have to be that big for axial gradients. It's sufficient to show they're constant across the axis and correct along the axis.
the theory lacks color checks yet that should be added, but it produces output images for visual control
somehow these don't look correct yet, containing hard edges sometimes.
The current implementation lacks accurrancy and prefers to be fast. For usual color gradients that shouldn't matter: They're quite smooth, for the black-white gradient on very small length's it's easy to spot these rounding errors as they affect whole pixels one can count manually.
- move to GradientBrushes namespace - add abstract base class for Gradient Brushes, that implements the GetGradientSegment implementtion and the color picking.
…rawing tests, as @antonfirsov suggested.
as requested by @antonfirsov.
changing parameters so that visual evaluation of correctness is easier.
Gradient Brushes
Prerequisites
Description
Implementing Gradient Brushes:
Color Repetition Modes
What's missing
What I'd like to add in future PRs: