| Summary: | performance decrease compared to stable release | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | kdebob |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | normal | CC: | griffinvalley, halla |
| Priority: | NOR | ||
| Version First Reported In: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
kdebob
2016-02-29 16:24:11 UTC
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! |