D23881: Possible solution for scheduling repaints on NVIDIA

ekurzinger added a comment.


  Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?

INLINE COMMENTS

> glxbackend.cpp:339
> +
> +        QMetaObject::invokeMethod(m_asyncSwapHandler, &AsyncSwapBuffersHandler::makeCurrent, Qt::QueuedConnection);
> +    }

Is this necessary? If the swap thread isn't rendering anything I don't think it actually needs a current context, right?

> glxbackend.cpp:786
> +            if (m_asyncSwapHandler) {
> +                glFlush();
> +                QMetaObject::invokeMethod(m_asyncSwapHandler, &AsyncSwapBuffersHandler::swapBuffers, Qt::QueuedConnection);

I'm not 100% sure this is sufficient to ensure all rendering is complete before the swap. It only guarantees that any commands have been submitted to the GPU, but not necessarily that they've all finished executing. Furthermore, glXSwapBuffers should cause an implicit glFlush anyway.

For instance, the glXSwapBuffers spec mentions glFinish for this purpose:

> All GLX rendering contexts share the same notion of which are front buffers and which are back buffers. One consequence is that when multiple clients are rendering to the same double-buffered window, all of them should finish rendering before one of them issues the command to swap buffers. The clients are responsible for implementing this synchronization. Typically this is accomplished by executing glFinish and then using a semaphore in shared memory to rendezvous before swapping.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D23881

To: fredrik, #kwin, romangg
Cc: ekurzinger, kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, mart