As soon as I get it fully working, I want to try to reduce the spectral primaries from 36 down to something like 5 or 10 and see if that works. That should bump performance up a lot. But yeah, it’s going to be slower. There are some settings that can dramatically improve smudge performance, in general, though. For instance, if you increase the smudge length setting (and even use the smudge length multiplier to lengthen this exponentially) you can reduce the amount of times the canvas is sampled ( thus reducing triggering smudge code). This is practically required for brushes with lots of small dabs, like we are doing with the flat brushes. On the plus side, extending the smudge length lets you “smear” paint much much farther (while simultaneously increasing performance). So, definitely try my brush pack flat brush that I’ve tuned a bit and see if it’s better. I don’t have any lag on my desktop but it is a pretty beefy Intel core i7.
That’s not right. Hmm… Are you using the latest commit from 3 days ago? I switched out the spectral curves with some new ones for no particular reason other than to try using curves generated straight from python’s colour-science library instead of the Scott Burns curves. That might have screwed up something since. I’ll try to reproduce this and I might go back to Scott Burns curves. In fact, yeah, I think I will for a few other reasons.
Well, the settings are definitely intertwined with color science (of which I still have a LOT to learn). I didn’t want to hard-code it so that subtractive mode always uses spectral and a pow 2.4, but it could be that that is the best configuration since it is the most physically plausible model. I kind of like keeping it flexible so you can really see how a power function affects blending, etc etc. Especially in the brush editor “live update” mode.
Stay tuned, I hope (in the next day or so) to have the canvas sampling code updated to improve spectral blending even more, resulting in more saturated color blending. Right now whenever you sample the canvas for a color (this is smudge length setting), MyPaint sums up the pixels from a small area of the canvas and averages them together-- essentially an additive function. So if you have blue and yellow pixels near each other and you sample that, you’ll get a grey or even white color.
There are two ways around this that seem feasible. One is to use a kmeans clustering algorithm to find the “dominant color”. I’ve implemented this in the CIECAM PR on the mypaint side, for the color picker. Seems to work pretty well. If you pick a region that has yellow and blue pixels, you’ll generally get back a yellow or a blue color that actually exists on the canvas instead of a greyish color. I’m thinking this can help avoid progressively duller and duller colors if your process involves a lot of color picking.
The other way around this is what I’m working on in the libmypaint side, which is to do the same kind of spectral subtractive color blending for all the pixels in the sampled area. So, yellow and blue pixels would be sampled as a green color instead of grey, and so on. Unfortunately this means even more processing overhead. . . but I don’t think it’s insurmountable, especially if I can reduce the spectral primaries from 36 to 5 or 10 like I was saying. Sorry for the wall of text. Please try my brushes and see if the performance is still bad