@Wertyus said in How to Display Frames in QML from C++ for Real-Time Applications:
Did you experience any latency issues with the QQuickPaintedItem approach when handling high frame rates (e.g., 30 FPS)?
I did some initial experiments to test the viability of the general approach and was able to get frame rates above 30fps. Since implementing the real thing, I have not explicitly measured this but it has been good enough for our purposes. In our case, the frames are provided not by a video stream but by a rendering of a 3D model provided by a back end server. Using QQuickPaintedItem was driven by our need to be able to react to mouse events and so on that are fed back to the server.
It might be that for your case, treating it as a video stream and using the specialised support for that would be more appropriate.
Also, how did you handle buffer updates efficiently when new frames arrived?
This is a sketch of the code in the QQuickPaintedItem. Because it's a "pull" approach, it is possible that frames could arrive too quickly for this to display all of them and anything between the last image requested and the current one will have been dropped.
void ViewerItem::checkForNewImage()
{
// Called on timer trigger
// Note no significant copying here.
// `imageProvider` works on separate thread; `currentImage()` is mutex protected internally
std::pair<std::shared_ptr<Image>, int> image = imageProvider->currentImage();
if (image.second != m_currentIndex) {
// New image - update the pixmap member
m_pixmap.convertFromImage(
QImage(image.first->pixelBuffer(),
image.first->width, image.first->height,
image.first->width*3, QImage::Format_RGB888
)
);
// New image so update index
m_currentIndex = image.second;
// update() is QQuickPaintedItem member - will call `paint(QPainter*)` on the present class
// our implementation of paint() uses `drawPixmap(0, 0, m_pixmap)`
update()
}
}
