Important: Please read the Qt Code of Conduct -

Best way to render video going forward - Given state of Mac OS, etc

  • So, I thought I would start a new topic on this, I feel like I'm going down a rabbit hole researching.

    The background: Our app is a video call app. It's built on an SDK. I subclass one of it's classes and re-implement it's lock an unlock functions. SDK grabs video frames from camera. When it has one, it calls the lock, where it fills a buffer I give it with raw image data. Then it calls unlock telling me the "image" is ready to render. We wanted this threaded because I can actually get up to 3 images (3 way calling, local and 2 remote frames) and have to resize them to fit current UI layout, then draw.
    Currently we ended up with 2 widgets. Originally (because it was the only example of threaded rendering in Qt I could find, why is this so difficult!) I wrote a QGLWidget using a shared widget to thread. It worked great on all platforms. Down the line I ended up having to do a separate D2D widget (non-threaded) for Windows because of another Qt bug where, on certain INtel graphics cards + OPenGL, the UI would simply loose all style at some point. Now we have Mac dropping OpenGL, running into issues in Catalina with our old OpenGL widget. We just introduced Linux to the mix and that's the only one working flawlessly still with the QGLWidget based surface.

    So, we have today. I am reading and see so many possibilities, but not enough info to determine which will really work, can be threaded, or will be future proof. I could waste time on one just to run into issues again! So far, I see these options but again I don't know which rabbit hole to go down, any suggestions or links to an example?:

    • RHI. This seems at the surface like it would be great. One surface for all again. But... It's not until 6.x, there's no real docs yet, and I found a single example (the cinema experience) but that's qml/quick/ Can it be used in a Widgets based app? Can it be threaded? Can it even be used for what I'm doing or is it more for Qt UI itself?

    • QSurface and QOffScreenSurface. By their description, it would seem they could be used to replace my current widgets but use Metal, OpenGL, etc based on platform. But, NO examples found and the docs don't indicate any functions for rendering.

    • Re-write my current QGLWidget to use the newer QOpenGLWidget. Will this still be supported on Mac OS? For how long? Will it do away with the loss of style issue so I can use in Windows again too? I did find a threaded example of this and got about half way to using it for our purposes, but didn't want to waste more time not knowing if it will continue to work in Mac OS anyways given the loss of OpenGL.

    • Is there some other, better solution I'm missing?

    Any info is appreciated. For now, the app still works in all env, but we are starting to get feedback about performance on Windows, and it was a close call with Catalina keeping the QGLWidget working.
    If it helps, here is the relevant part of the "lock" function from the SDK showing the format I receive, currently being put into a QImage in the current implementations:

    int bufferSize = pixWidth*pixHeight*4;
    uchar *pBuffer = (uchar*)ALLOC_ALIGN16(bufferSize);
    memset(pBuffer, 0x0, bufferSize);
    m_Data[currentTail] = new QImage(pBuffer, pixWidth, pixHeight, (pixWidth*4), QImage::Format_ARGB32_Premultiplied, &myImageCleanupHandler, pBuffer);

  • Lifetime Qt Champion


    I think that one of the answer you'll get will be to move to QOpenGLWidget because QGlWidget is deprecated.

    AFAIK, the plan is to keep QOpenGLWidget and have the new architecture manage things underneath. You should already be able to do some testing with the next releases of Qt which will pave the way for Qt 6y

    As for the more internal parts, you should bring this to the interest mailing list. You'll find there Qt's developers/maintainers. This forum is more user oriented.

Log in to reply