- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 888
Gradient Brushes #542
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
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.
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: