Krita, Qt and OpenGL — again.

I have previously written about this subject, and back then couldn’t reach any conclusion. The options open to us were all confusing: we could try to write Krita’s canvas directly in Metal, OpenGL and Direct3D and show those in native windows in our QtWidgets based application.

We could try to rewrite our canvas in QRhi, the semi-private GPU API  abstraction Qt 5.15 and up provides — though it might not have enough functionality for us, since it us just written for what Qt needs for QtQuick.

We could try to rewrite all of Krita in QtQuick and integrate our canvas into QtQuick’s render loop: but yes, that means a complete rewrite, because you cannot put a QWidget in a QtQuickWindow, and putting QtQuick into a QWidget window means you’re rendering using OpenGL, which breaks on Windows, now that Qt6 doesn’t come with an Angle option.

So we had a big blue button meeting on Friday, where we discussed this issue and some other issues.

Here’s what we concluded:

We will patch Qt6 to render OpenGL using Angle on Windows and macOS.

In the meantime, using Qt 5.12, we’ll move forward adding QtQuick based elements to Krita.

And we’ll try  to make a QtQuickWindow based version of Krita for Android. Sharaf Zaman has succeeded in prototyping that, so we know it can be done now; something we lost in the migration from Qt4 to Qt5.

We also want to strip out the CPU-based canvas in Krita and port our usage of QPainter on OpenGL surfaces to straight OpenGL.

And finally, something we should have done during the port to Qt5, we’ll move uploading the canvas textures into a thread, which should solve the performance problems on macOS.

All in all, it was a very focused and very productive meeting, though I guess the conclusion might be a bit startling. And we’re a bit daunted, but only a bit: we already patch the heck out of Qt anyway.