Might make more sense to actually move the OpenGL rendering code to another thread... iirc Boud considered doing this some time ago.

@alvinhochun @rempt This is definitely the right idea and it would be so great having this as it's the one central performance hog on macOS. Alas, I spent a day last week trying to do exactly that and had to find out that with the current QT implementation there's seemingly no way to do it. It used to be possible with QT 4. But with QT5 and QTQuick, the compositing in the main thread doesn't inform any other thread of when the context is occupied and QT crashes with an assertion that a context cannot be used by two threads. The official sample code (https://github.com/qt/qtbase/blob/5.9/examples/opengl/threadedqopenglwidget) is a hack and only works as long as the OpenGL runs in a separate window without other widgets; if there are any other widgets in the other, QT's compositing code fails to properly call onAboutToCompose and onFrameSwapped and so the whole fragile GL context grabbing logic breaks down. It's sad state of affairs with QT.

I like it.

Hi, @poke1024!

Could you check if glSync functionality actually works for you (m_d->canvasWidget->isBusy())? Because that is an already present functionality on limiting FPS. It doesn't issue one more frame until the previous one is fully processed.

To check that glSync functionality works, you need to activate "Enable debug logging of openGL framerate" in the performance tab, restart Krita and then look into the debugging output. You should lines like:

glSync effectiveness: 0.0818363

If "effectiveness" is exactly 0.0 or 1.0, then glSync doesn't work and you should try to fix it first. If not, then the patch is perfectly fine to be pushed.

So please check glSync() thing and, if it works fine for you, just push the patch. If not, we should work on the fix further

PS:
Qt must *not* drop any tablet events even if the main event loop is busy 100% of the time. That is what we fought for on Linux and Windows, and the same thing should be on OSX. We will never manage to make main thread free enough to guarantee responsiveness at 8 (!) ms, which is the rate at which tablet events come.

To achieve that, we might have to re-implement Qt's tablet support ourselves, like we do on Windows and OSX...

In D8193#153655, @rempt wrote:

To achieve that, we might have to re-implement Qt's tablet support ourselves, like we do on Windows and OSX...

Or just patch it before building as we did a couple of times :)

Anyway, it is still not much related to the patch in question.

Hi @dkazakov,

the glSync functionality works for me as expected (e.g. glSync effectiveness: 0.0598802).

The QT "no drop" situation is good to hear :-) Though I still get the impression that there is someone dropping on OS X. Might be the OS, might be Wacom's driver. Nothing I can pinpoint, just the impression that some random jerkiness is going on. But it's good to know that QT gives us everything it gets.

I'll push this now.

pushed to master.

https://commits.kde.org/krita/4cb82985c37e07d8e628094fb137169c35ac1df6