Color picker lags behind cursor to the point that the whole program becomes unresponsive for several seconds. Brushes and other tools apply significantly slower and are less responsive. G'MIC filters report longer times and filters seem to apply slower in general. Reproducible: Always Steps to Reproduce: 1. Start Krita 2. Open/Create Document 3. Use Color Picker/Filters/Brush/Fill Tool Actual Results: Actions are performed a lot slower than on 2.9.11. Expected Results: Actions are performed about as fast as on 2.9.11. OpenSUSE Tumbleweed Intel Core Duo E8500 GeForce GTX 750 Ti with binary NVIDIA drivers version 361.28 (also tested with 358.16) The Alpha appimages don't exhibit all of these problems and actually seem to be faster where they aren't slower. I still experience the color picker problem on them. Strokes also apply as fast, if not faster, as on 2.9.11, but become increasingly slower as you decrease the brush size.
The last sentence is because Instant Preview just loses it's use at small sizes, hence why it can be configured in both the brush settings as well as globally under view. The rest of the bugreport I am not sure what to do with, perhaps the RPMs are missing a dependancy?
(In reply to wolthera from comment #1) > The last sentence is because Instant Preview just loses it's use at small sizes, hence why it can be configured in both the brush settings as well as globally under view. > > The rest of the bugreport I am not sure what to do with, perhaps the RPMs are missing a dependancy? I made sure to disable instant preview to have a meaningful comparison to stable, so it must be unrelated. It shouldn't affect the appimages if it's a dependency issue right?
Check that the opensuse rpm's are built with Vc; if they aren't, then that explains the difference in painting performance.
I cannot reproduce any of these observations. It would also be really strange, since e.g. the code for filters hasn't changed at all, the code for accessing pixels hasn't changed. Such a broad difference sounds to me like opensuse built krita in full debug mode without optimizations. Please contact the opensuse maintainers about how they build their packages?
I think I made a mistake when I submitted the bug. Sorry for causing confusion, but when I selected openSUSE RPM as platform I actually meant I'm having these issues with the Krita appimages and Krita master compiled from source on openSUSE Tumbleweed, not with any openSUSE Krita package. I built them with Vc. However, I just made a new build from master and I can't reproduce these issues anymore. I still experienced the "sluggish brush that gets worse with smaller brush size" issue mentioned on the recent appimage release (third), so I assume whatever caused it was fixed between then and now. Advanced Color Selector is now the only thing that is slower on any version of 3.0 I tried, but I guess this was unrelated and doesn't fall under the topic of general performance issue anymore.
are you using the hsy selector? because then that's expected(the hsy selector is now linearised giving it true luminance).
(In reply to wolthera from comment #6) > are you using the hsy selector? because then that's expected(the hsy > selector is now linearised giving it true luminance). It doesn't matter which color model type or color space I use. The only thing which seems to make a difference is restarting with opengl disabled, which isn't worth it for such a minor issue. It affects the Advanced Color Selector, Small Color Selector and Artistic Color Selector. Only encountered the problem on 3.0.
(In reply to Boudewijn Rempt from comment #4) > I cannot reproduce any of these observations. It would also be really strange, since e.g. the code for filters hasn't changed at all, the code for accessing pixels hasn't changed. I made a new build with source code that should be older than appimage alpha 3. Unlike the appimages, it also doesn't have the unbearable slow brushes anymore, so I guess it wasn't a krita, but a dependency update that made it work on my system.
Thanks for checking!