IIRC, it was KisResourceCacheDb::metaDataForId where lot of time was spent in prepare().

sure, I'll look into it then :)

A thing I found out when I was profiling the code for https://invent.kde.org/graphics/krita/-/merge_requests/1731, is the QSqlQuery::prepare being a bottleneck. I looked into a docs a bit and found out that prepared queries are "compiled" by sqlite into whatever its internal bytecode can understand, so this is something which doesn't need to happen over and over again, but something we can cache and only bind values whenever needed (I think Qt's QSqlQuery::exec takes care of resetting the bindings and re-executing the same prepared query).

In T13339#251760, @woltherav wrote:

Concerning the opengl depth test stuff, there's some mention of it in the qt6 docs: https://doc.qt.io/qt-6/qquickgraphicsconfiguration.html
That class doesn't exist in 5, the only mention I can find is that the depth buffers got to be reset: https://doc.qt.io/qt-5/qquickwindow.html#resetOpenGLState

I guess that means I could get rid of the blending mode stuff? I'll test on thursday.

I've ported the canvas (as suggested a week back in IRC) to use Kirigami's ApplicationWindow as a starter: https://invent.kde.org/szaman/krita/-/commits/krita-qml

In T14170#251066, @woltherav wrote:

So... if we would want to port, then the filters, settings, new image dialog, impex-dialogs and other things we keep in separate windows can be done first, but dockers will all need to be ported in one go?

Alright, then the next question. Halla is thinking about using KDDockWidget. If we'd use that here, will that lead to the same issue?

In T14170#250954, @sh-zam wrote:

In T14170#250953, @woltherav wrote:

This is also starting to sound like we should just get someone to just sit down and write a test program within a week (just basically a window with the aforementioned combos of qtquickwidgets, regular widget, opengl or qrhi widgets, etc) and just see what that uses on the different platforms? I think it might prove time saving?

There is an app above which uses QQuickWidget, QWindow (in a window container) and a normal QWidget. It worked fine on Linux. I can test it on Windows, MacOS may be for @rempt / amyspark.

In T14170#250953, @woltherav wrote:

This is also starting to sound like we should just get someone to just sit down and write a test program within a week (just basically a window with the aforementioned combos of qtquickwidgets, regular widget, opengl or qrhi widgets, etc) and just see what that uses on the different platforms? I think it might prove time saving?

In T14170#250905, @dkazakov wrote:

Window Container based approach

There will be one more problem of this approach. The outer window will still be rendered by Qt and will use opengl.dll.

I've built the x86 APK from release tarball: https://drive.google.com/file/d/1-DZipSmIdJSIfRvYVKAwMtK4ame8h4P9/view?usp=sharing