GPU Drawing Effect Questions

[Rick Brewster]

For rotation you can use deviceContext.UseRotationAt(), which will push and pop the appropriate changes to the Transform property. You should use it with a using block.

 

I’ve got more notes to add. I’d have replied with more sooner but I’m currently nursing an arm/wrist/hand injury so I’m limited to mousing and typing with one hand 

 

 

[Red ochre]

I'm sorry @_koh_, I assumed you were being sarcastic and reacted badly due to past experiences on this forum.

I could not get deviceContext.Transform to show up in codelab but I was trying to access it below where I had defined my ellipse. May try again tomorrow.

Apologies again.

 

Just seen your post @Rick Brewster - No problem - get yourself well again!

[_koh_]

36 minutes ago, Red ochre said:

I'm sorry @_koh_, I assumed you were being sarcastic and reacted badly due to past experiences on this forum.

 

No problem. My english isn't that capable, so I wasn't even aware of you were reacting badly😅

[Tactilis]

1 hour ago, _koh_ said:

My english isn't that capable, so I wasn't even aware of you were reacting badly

 

I am English and I didn't perceive any bad reaction by @Red ochre 😉

 

 

By the way @_koh_, when RO said:

  

3 hours ago, Red ochre said:

I'll get my coat.😕

 

he is referring to https://en.wiktionary.org/wiki/I'll_get_my_coat

 

There's much to get lost in translation!

 

 

 

[_koh_]

30 minutes ago, Tactilis said:

he is referring to https://en.wiktionary.org/wiki/I'll_get_my_coat

 

There's much to get lost in translation!

 

Ah. I just took it as AFK and thought, yeah sounds like he's busy.

[Rick Brewster]

On the subject of color spaces and "companded" vs. "linear", I would like to suggest compiling against the 5.1 Beta. I don't think CodeLab supports ManagedColor yet. It firstly provides a color value that is tagged with its color space, and makes it very easy to retrieve the color value you need to use for the device context's color space. Second, it provides a ManagedColorProperty for use with IndirectUI that is a better way of implementing a Color Wheel than the goofy way I repurposed Int32Property.

 

The whole notion of taking the ColorBgra32, casting to SrgbColorA, then LinearColorA, then ColorRgba128Float ... etc. This was an alright solution for 5.0, but it has actually quickly become obsolete with the color management systems in 5.1 which are substantially more sophisticated and hopefully not more complicated. I would also really like to have another person trying out the new API (ManagedColor) to get some feedback on it.

 

The code would look kinda like this:

// This is now of type ManagedColor instead of ColorBgra32
ManagedColor primaryColorM = Environment.PrimaryColor; 

// You can also use a ManagedColorProperty with IndirectUI to let the user select a color with a Color Wheel
// e.g. ManagedColorProperty mcm = new ManagedColorProperty(PropertyNames.Color1, Environment.PrimaryColor, ManagedColorPropertyAlphaMode.SupportsAlpha);

// Behind the scenes, the device context is tagged with the appropriate color space / color context
// I've rigged it up so _you_ don't have to worry about color space or color context or linear or companded or whatever
// Because what _you_ want is just the appropriate color value for rendering with the device context
ColorRgba128Float primaryColor = primaryColorM.Get(deviceContext); 

ISolidColorBrush primaryBrush = deviceContext.CreateSolidColorBrush(primaryColor);
deviceContext.FillRectangle(..., primaryBrush); // or draw whatever you want of course

 

(I'm still catching up on the rest of the thread...)

[Rick Brewster]

21 hours ago, _koh_ said:

I'm saying you can do this to clamp sample coordinate.

 

int mcxi = (int)Math.Clamp(mcx, selection.Left, selection.Right);
int mcyi = (int)Math.Clamp(mcy, selection.Top, selection.Bottom);

 

You'll actually need to clamp to Right-1 and Bottom-1 if you're going to pass these to something like RegionPtr<T>'s indexer (or anything that treats a bitmap effectively as an array)

[Rick Brewster]

On 8/31/2024 at 4:04 PM, Red ochre said:

ColorBgra PC = Environment.PrimaryColor;//thanks Rick!

 

Highly recommend not using ColorBgra anymore, and instead using ColorBgra32. They have implicit casts between each other, but ColorBgra is the "old" color class with a lot of baggage and other weird-isms from 2004 through 2010 or so. It hasn't really seen any improvements or upgrades since then.

 

But also it's just nice to be consistently using the new types and systems.

 

I do plan on eventually tagging ColorBgra with [Obsolete]. There's a lot of internal PDN code that needs to be migrated first (which I just haven't gotten to)

[Rick Brewster]

On 8/31/2024 at 4:04 PM, Red ochre said:

IStrokeStyle PriStrokeStyle = deviceContext.Factory.CreateStrokeStyle(StrokeStyleProperties.Default);

 

btw if you're going to use the default stroke style you can just use null instead. The default value for a stroke style parameter is always null so you can usually just omit it entirely.

 

I saw this in @Ego Eram Reputo's code too

[Rick Brewster]

On 8/31/2024 at 4:04 PM, Red ochre said:

double dist = Math.Sqrt((Xdiff * Xdiff) + (Ydiff * Ydiff));

 

btw .NET now has a MathF class which can help to avoid a lot of casting back to float after using Math for calculations that result in doubles.

 

Personally I like to keep everything as double until the very end and only cast to float for the actual drawing calls.

[Rick Brewster]

On 8/31/2024 at 4:04 PM, Red ochre said:

C1 = (byte)((iDrat * PC.R) + (Drat * SC.R));//use companded colorspace to mix

 

On 9/1/2024 at 2:10 AM, _koh_ said:

How brush color interact image color is a human perception thing in my view, so using sRGB brush is my preferable choice so far.

 

I strongly disagree. Using companded values does work very well for certain calculations, but not for blending or sampling. The only reason to do blending or sampling in companded space is if you really want to mimic how the drawing tools and layer blend modes currently operate. They are going to be upgraded to support linear, hopefully in the 6.0 timeframe along with all the revamps and upgrades for the .PDN file format and FileType plugins.

[Rick Brewster]

This is an example of a simple GpuDrawingEffect btw. Not sure if I already linked to it: https://github.com/paintdotnet/PdnV5EffectSamples/blob/main/Gpu/RainbowGpuEffect.cs

[_koh_]

13 hours ago, Rick Brewster said:

Using companded values does work very well for certain calculations, but not for blending or sampling.

 

While I understand linear blending gives me physically accurate results, when I use a brush, I'm trying to change the image color by perceivable amount, and usually have intended result in mind. So getting the physically accurate average for given colors / alphas isn't my priority, it only needs to function in a predictable / controllable manner.

 

sRGB scale / linear scale

Our eyes are more sensitive to the darker tones, and gamma encoded color spaces are adjusted for that.
Using a brush is like adjusting sliders along these scales. So it's more easier to get the intended color with sRGB brush than linear one.

I may change my mind when I actually used linear brush, but this is how I see things for now.

 

edit:

Some tests. Umm, I can't decide.

 

B -> R gradation looks better in linear. sRGB(0.5, 0, 0.5) looks visibly darker than (1, 0, 0) or (0, 0, 1) as expected.

 

sRGB / linear

Brush size looks consistent in sRGB.

 

sRGB / sRGB inverse

 

linear / linear inverse

 

edit2:

Feels like
when R:G:B is consistent, sRGB gradation looks linear
when R+G+B is consistent, linear gradation looks linear
this... kinda making sense.

 

I wonder how Lab gradation will look. Covers both cases?
I know its purpose but never actually tested.
 

[Red ochre]

On 9/3/2024 at 2:14 AM, Rick Brewster said:

I saw this in @Ego Eram Reputo's code too

Same source! 🙂 https://boltbait.com/pdn/CodeLab/help/tutorial/drawing/

 

Hope your finding it easier to type now, no problem with quick replies - I have many less enjoyable real life chores to get on with.

Everything you have written has been very useful but it may be a few days before I can efficiently ask about the (still many) things I don't understand, but thanks for keeping an eye on this thread.

[BoltBait]

46 minutes ago, Red ochre said:

Same source! 🙂 https://boltbait.com/pdn/CodeLab/help/tutorial/drawing/

 

Yes, what @Rick Brewster says is true.  However, putting null in the example code would be much less discoverable than showing how to create the default.

 

I think someone following the example might see "StrokeStyleProperties.Default" and get curious to see what else could replace "Default" there.

 

[Red ochre]

Didn't mean to criticize  @BoltBait and your tutorials are appreciated!... yet the options for dashes etc. seem less than obvious.

An example of how to set the StrokeStyle would be really useful!... syntax isn't always obvious.

... Possibly obvious for experienced coders, (but they probably don't need a tutorial)... very difficult to set the understanding threshold but as someone who has learnt a lot from your tutorials, I think the more you put in the better. The reader can then cross-reference what you have said and gain a better understanding.

 

So yes, I am curious, but don't find the ways to set StrokeStyleProperties straightforward?- All code examples are really useful!

... and many thanks for all the previous tutorials (there wouldn't be a Redochre pack without them!).

 

[Rick Brewster]

1 hour ago, BoltBait said:

However, putting null in the example code would be much less discoverable than showing how to create the default.

 

Yup that's a perfectly good reason to do the sample code that way. And if someone never learns/realizes that they can just use null instead ... oh well. It's harmless. The benefit gained from stoking curiosity is better.