That crash in KoFontRegistry::fontMetricsForCSSValues sounds like it was probably fixed by commit 9f6b125d, maybe that build is a bit behind master?
Even on that old notebook I need to use:
- battery instead of wall power
- 15 layers (bottom one set to normal, others to e.g. darken)
- 10000 x 10000 px
- 300 ppi
- 16 bit integer
to make it obvious how much faster GL is.
If I add just one single filter layer (e.g. blur) though, it kills the performance easily even with less demanding settings.
In my case in the past when I only had an Intel graphic and now that I have Nvidia Direct3D works better than OpenGL, since the latter gives me several problems and is slower.
Okay, crash issue seems to be on my side, I will have a look at it on Monday
There are two known issues in Angle/D3D renderer:
- The usage of buffers for textures is slow (they should be disabled)
- We force a glFinish in the end of each frame, when Angle is used. That might be the main reason for the bad performance
We should probably investigate into how to avoid that…
I made another test on a different (faster) notebook - this time with memileo brush and smaller canvas size:
No canvas acceleration:
Software acceleration:
Direct3D via Angle acceleration:
OpenGL acceleration:
EDIT:
Has anybody else made a similar test? I have the feeling that all the acceleration options are not much faster than painting without acceleration?
No Acceleration → Hardware Accelerated makes a massive difference if you have a high desktop resolution like 4K and you’re rotating/panning/zooming the canvas. This is the main purpose of this acceleration after all.
Just making the brush strokes may actually be faster in pure software mode, as you don’t need to update the GPU memory (on the application level at least).
Ah ok. I just tested moving and rotating layers. Accelration is faster there. But GL is smoother than Direct3D in that case as well.
Hi, @cgidesign!
Thanks for the videos. Now I see what you all mean. I’ll check what I can do with that.
Dear @dkazakov
many thanks for your work and that of all the others involved in Krita. I like Krita as it is already (CSP and Affinity Photo are gathering dust on my machine when painting is involved).
Beside Krita being a great tool already, I think, its performance has room for improvement.
While you are anyway having a look into that, I like to post two more videos. One shows Krita 5.3 performance with filters, the other one shows Affinity Photo as a comparison (OpenCL acceleration was not active in A-Photo during the recording). Seeing the difference between the two, it seems to me Krita has a big handbrake on somewhere in it, that hinders it to show its sprinter muscles.
Krita 5.3 (Direct3D via Angle but the other options are similar in speed).
Affinity Photo 2.6
How large was the Gaussian Blur radius?
50 in A-Photo and 100 in Krita. The difference was needed to get a similar softness. If I use 50 in Krita then the result is less blury than in A-Photo.
With 50 Krita gets a bit faster, but it is still way slower than A-Photo.
You could also disable the blur filter and only use the curves. It also shows the speed difference between the two.
Edit:
The cross bitmaps are a bit different in both apps. To be on the save side I exported the cross from Krita and used it to replace the one in A-Photo. A-Photo got a bit slower by this but was still faster than Krita.
Why bother at all?
I found an old 3d render of mine and used Krita for a bit of editing.
Before:
After:
Even though the file is not demanding (1200 x 900 px, 96ppi, 16 bit), the editing was challenging speedwise.
Here is an example recorded on my faster notebook mentioned in a previous post.
i am confident that the Krita team is as smart as the employees from Canva (new owner of Affinity) or Adobe. So I bet there is a lot of speed potential hidden in Krita.
For me openGL is fairly fast on my system but I think Direct3D11 is a tiny bit faster so I use it more often even on stuff like OBS.
My Krita View3D plugin creates a docker with an OpenGL viewport and seems to only work with Krita set to “OpenGL” mode (last time i checked anyway). I haven’t actually investigated the “why” since i’m using Linux as my main OS and barely boot Windows.
It is most likely some conflict between using native OpenGL and ANGLE. In theory it shouldn’t matter since i’m creating a new context and all, though i don’t know how deep ANGLE goes (i never used it) - perhaps i’ll move all the OpenGL stuff to the C library (the plugin was originally Python-only) at some point in the future and use Qt just for obtaining a window handle (or pass a window handle to Qt and hope for the best).
Hi, @cgidesign, @Michelist and @YRH!
Could you please test this package?
krita-6.0.0-prealpha-angle-perf-dk1.zip — Яндекс Диск
Basically, try running it in openGL and DirectX modes and compare the performance. You can also enable the FPS printing on Preferences->Performance page.
Ideas for testing:
- FPS while painting with some brushes
- FPS when panning (was bad in Krita 5 + ANGLE)
- FPS when zooming (was bad in Krita 5 + ANGLE)
PS:
It is a preliminary version of Krita 6 based on Qt6, so it might not be fully functional. Though HDR should work already
UPD:
This version of Krita has a heavily patched Qt that limits the framerate to the highest framerate of available displays. In Qt5 we had this limit, but only for painting. This patch moves this feature to the level of Qt, hence the effect now also apply to zooming and panning actions.
Hi Dmitry, this build doesn’t like my system either. Now I’m getting a stack overflow (haven’t seen that in a while!):
Exception thrown at 0x00007FF9DE8BC5C0 (ntdll.dll) in krita.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000005240EB3FF8).
Unhandled exception at 0x00007FF9DE8BC5C0 (ntdll.dll) in krita.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000005240EB3FF8).
> ntdll.dll!00007ff9de8bc5c0() Unknown
ntdll.dll!00007ff9de8bbfc4() Unknown
ntdll.dll!00007ff9de8bbe86() Unknown
ucrtbase.dll!00007ff9dc350139() Unknown
icuuc-72.dll!00007ff9223b1029() Unknown
icuin-72.dll!00007ff922196727() Unknown
icuin-72.dll!00007ff922196846() Unknown
icuin-72.dll!00007ff9221976b1() Unknown
icuin-72.dll!00007ff92216752f() Unknown
icuin-72.dll!00007ff922166c0d() Unknown
icuin-72.dll!00007ff9221253c6() Unknown
icuin-72.dll!00007ff922125bab() Unknown
icuin-72.dll!00007ff922198d3e() Unknown
Qt6Core.dll!00007ff923fb82bf() Unknown
Qt6Core.dll!00007ff923fb80c2() Unknown
Qt6Core.dll!00007ff923faed8f() Unknown
Qt6Core.dll!00007ff923faf20e() Unknown
Qt6Core.dll!00007ff923fb812d() Unknown
Qt6Core.dll!00007ff923faed8f() Unknown
Qt6Core.dll!00007ff923faf20e() Unknown
Qt6Core.dll!00007ff923fb812d() Unknown
... (looping)
There is no crash log produced in kritacrash.log and I see no other indication as to what’s wrong. I tried running with all possible canvas acceleration modes, and the software only mode (set in the settings before launching your build), but the result was the same.
Regarding the FPS, it’s difficult to measure performance with it because AFAICT Krita doesn’t present the frames continuously (like a game), and only refreshes on-demand. The only way to see an indication of max FPS is to move your canvas frantically to provoke a refresh and try to notice the number. At least that’s my experience on Windows in Krita 5.x.
I haven’t looked at how it’s implemented, but is it possible to change the rendering to present the frames as fast as possible?
For what its worth, that crash is happening in ICU, which is a C unicode library, so much like the previous crash you were dealing with: It’s text related, not OpenGL related. Though, kind of amusing that the text work just doesn’t want to let you test opengl
Hi, @YRH!
Is it possible to try to run the previous package with debugging symbols?
Here is the archive with debugging symbols (be careful, it is 1.2GiB compressed and 5GiB uncompressed):
krita-6.0.0-prealpha-angle-perf-dk1-dbg.zip — Яндекс Диск
Just uncompressed it into the same folder where you uncompressed the previous package (i.e. krita-6.0.0-prealpha-angle-perf-dk1
) and try to get the crash with the backtrace.
PS:
I understand the the debugging package is huge, so it might be difficult to test. It is a known issue of the Krita-Qt6 builds. We still need to fix its size.
Not a problem:
* thread #1, stop reason = Exception 0xc00000fd encountered at address 0x7ffe8450b295
frame #0: 0x00007ffe8450b295 ntdll.dll`RtlProtectHeap + 9765
* frame #1: 0x00007ffe844dc20e ntdll.dll`RtlAllocateHeap + 3694
frame #2: 0x00007ffe844dbe86 ntdll.dll`RtlAllocateHeap + 2790
frame #3: 0x00007ffe8457abfc ntdll.dll`RtlGetUserInfoHeap + 4220
frame #4: 0x00007ffe8450b8c3 ntdll.dll`RtlProtectHeap + 11347
frame #5: 0x00007ffe844dc20e ntdll.dll`RtlAllocateHeap + 3694
frame #6: 0x00007ffe844dbe86 ntdll.dll`RtlAllocateHeap + 2790
frame #7: 0x00007ffe81b70139 ucrtbase.dll`_malloc_base + 57
frame #8: 0x00007ffde61d1029 icuuc-72.dll`icu_72::UMemory::operator new(unsigned long long) + 9
frame #9: 0x00007ffde64363e3 icuin-72.dll`icu_72::InitialTimeZoneRule::clone() const + 19
frame #10: 0x00007ffde64376a4 icuin-72.dll`icu_72::TimeZoneTransition::TimeZoneTransition(double, icu_72::TimeZoneRule const&, icu_72::TimeZoneRule const&) + 36
frame #11: 0x00007ffde640752f icuin-72.dll`icu_72::SimpleTimeZone::initTransitionRules(UErrorCode&) + 1695
frame #12: 0x00007ffde6406c0d icuin-72.dll`icu_72::SimpleTimeZone::getNextTransition(double, signed char, icu_72::TimeZoneTransition&) const + 333
frame #13: 0x00007ffde63c53c6 icuin-72.dll`icu_72::OlsonTimeZone::initTransitionRules(UErrorCode&) + 1494
frame #14: 0x00007ffde63c5bab icuin-72.dll`icu_72::OlsonTimeZone::getPreviousTransition(double, signed char, icu_72::TimeZoneTransition&) const + 91
frame #15: 0x00007ffde6438d3e icuin-72.dll`ucal_getTimeZoneTransitionDate_72 + 158
frame #16: 0x00007ffde81a82bf Qt6Core.dll`ucalTimeZoneTransition(void**, UTimeZoneTransitionType, long long) + 239
frame #17: 0x00007ffde81a80c2 Qt6Core.dll`QIcuTimeZonePrivate::data(long long) const + 130
frame #18: 0x00007ffde819ed8f Qt6Core.dll`QTimeZonePrivate::displayName(long long, QTimeZone::NameType, QLocale const&) const + 79
frame #19: 0x00007ffde819f20e Qt6Core.dll`QTimeZonePrivate::abbreviation(long long) const + 94
frame #20: 0x00007ffde81a812d Qt6Core.dll`QIcuTimeZonePrivate::data(long long) const + 237
... (looping)
frame #7074: 0x00007ffde819ed8f Qt6Core.dll`QTimeZonePrivate::displayName(long long, QTimeZone::NameType, QLocale const&) const + 79
frame #7075: 0x00007ffde819f20e Qt6Core.dll`QTimeZonePrivate::abbreviation(long long) const + 94
frame #7076: 0x00007ffde81a812d Qt6Core.dll`QIcuTimeZonePrivate::data(long long) const + 237
frame #7077: 0x00007ffde819f737 Qt6Core.dll`QTimeZonePrivate::stateAtZoneTime(long long, QFlags<QDateTimePrivate::TransitionOption>) const + 167
frame #7078: 0x00007ffde80b2f67 Qt6Core.dll`QDateTimePrivate::localStateAtMillis(long long, QFlags<QDateTimePrivate::TransitionOption>) + 215
frame #7079: 0x00007ffde80b34db Qt6Core.dll`refreshZonedDateTime(QDateTime::Data&, QTimeZone const&, QFlags<QDateTimePrivate::TransitionOption>) + 139
frame #7080: 0x00007ffde80b31d0 Qt6Core.dll`QDateTimePrivate::create(QDate, QTime, QTimeZone const&, QDateTime::TransitionResolution) + 128
frame #7081: 0x00007ffde80ad52a Qt6Core.dll`QDate::startOfDay(QTimeZone const&) const + 122
frame #7082: 0x00007ffde80ae342 Qt6Core.dll`QDate::startOfDay() const + 50
frame #7083: 0x00007ffde81b34c0 Qt6Core.dll`QDateTimeParser::getMinimum(QTimeZone const&) const + 208
frame #7084: 0x00007ffde81b3039 Qt6Core.dll`QDateTimeParser::baseDate(QTimeZone const&) const + 121
frame #7085: 0x00007ffde81b3174 Qt6Core.dll`QDateTimeParser::fromString(QString const&, QDate*, QTime*, int) const + 116
frame #7086: 0x00007ffde80b1aa4 Qt6Core.dll`QDate::fromString(QString const&, QStringView, int, QCalendar) + 308
frame #7087: 0x00007ffde80b1b4a Qt6Core.dll`QDate::fromString(QString const&, QStringView, int) + 74
frame #7088: 0x00007ffdd87d88f8 qschannelbackend.dll`QAsn1Element::toDateTime() const + 248
frame #7089: 0x00007ffdd87cedb4 qschannelbackend.dll`QTlsPrivate::X509CertificateGeneric::parse(QByteArray const&) + 2260
frame #7090: 0x00007ffdd87ce418 qschannelbackend.dll`QTlsPrivate::X509CertificateGeneric::certificatesFromDer(QByteArray const&, int) + 232
frame #7091: 0x00007ffde79a8b12 Qt6Network.dll`QSslCertificate::QSslCertificate(QByteArray const&, QSsl::EncodingFormat) + 242
frame #7092: 0x00007ffdd87e9cad qschannelbackend.dll`QTlsPrivate::X509CertificateSchannel::QSslCertificate_from_CERT_CONTEXT(_CERT_CONTEXT const*) + 109
frame #7093: 0x00007ffdd87dd1d8 qschannelbackend.dll`QSchannelBackend::systemCaCertificatesImplementation() + 248
frame #7094: 0x00007ffdd87dd019 qschannelbackend.dll`QSchannelBackend::ensureInitializedImplementation() + 201
frame #7095: 0x00007ffde7a5a66c Qt6Network.dll`QSslConfigurationPrivate::defaultConfiguration() + 172
frame #7096: 0x00007ffde7a4c901 Qt6Network.dll`QSslConfiguration::defaultConfiguration() + 17
frame #7097: 0x00007ffde7968a72 Qt6Network.dll`QNetworkRequest::sslConfiguration() const + 50
frame #7098: 0x00007ffde7a0787c Qt6Network.dll`QNetworkReplyHttpImpl::QNetworkReplyHttpImpl(QNetworkAccessManager*, QNetworkRequest const&, QNetworkAccessManager::Operation&, QIODevice*) + 444
frame #7099: 0x00007ffde7945329 Qt6Network.dll`QNetworkAccessManager::createRequest(QNetworkAccessManager::Operation, QNetworkRequest const&, QIODevice*) + 2521
frame #7100: 0x00007ffdeeb85923 libkritaui.dll`KisNetworkAccessManager::createRequest(QNetworkAccessManager::Operation, QNetworkRequest const&, QIODevice*) + 755
frame #7101: 0x00007ffde7943a5e Qt6Network.dll`QNetworkAccessManager::get(QNetworkRequest const&) + 30
frame #7102: 0x00007ffdeeb85605 libkritaui.dll`KisNetworkAccessManager::getUrl(QUrl const&) + 53
frame #7103: 0x00007ffdeeb88fba libkritaui.dll`MultiFeedRssModel::addFeed(QString const&) + 138
frame #7104: 0x00007ffdeebf8a4c libkritaui.dll`KisManualUpdater::checkForUpdate() + 156
frame #7105: 0x00007ffdee7d4bfe libkritaui.dll`KisWelcomePageWidget::KisWelcomePageWidget(QWidget*) + 2462
frame #7106: 0x00007ffdeeb2fbe6 libkritaui.dll`KisMainWindow::Private::Private(KisMainWindow*, QUuid) + 854
frame #7107: 0x00007ffdeeb17f01 libkritaui.dll`KisMainWindow::KisMainWindow(QUuid) + 193
frame #7108: 0x00007ffdeeb3d6cb libkritaui.dll`KisPart::createMainWindow(QUuid) + 75
frame #7109: 0x00007ffdeeb40a77 libkritaui.dll`KisPart::startBlankSession() + 23
frame #7110: 0x00007ffdeeac7d7c libkritaui.dll`KisApplication::start(KisApplicationArguments const&) + 9724
frame #7111: 0x00007ffdeef6766c krita.dll`krita_main + 25148
frame #7112: 0x00007ff727b21311 krita.exe`__tmainCRTStartup + 433
frame #7113: 0x00007ff727b21156 krita.exe`.l_startw + 18
frame #7114: 0x00007ffe82b1e8d7 kernel32.dll`BaseThreadInitThunk + 23
frame #7115: 0x00007ffe8457bf6c ntdll.dll`RtlUserThreadStart + 44
Just for testing purposes you can try disabling fetching the news on the start page. It seems to be related in some way We can look at the actual problem later on.