-
Another approach might be using QQuickRenderControl and QQuickRenderTarget to render a QQuickWindow to an offscreen buffer so the application can determine when to swap that buffer on screen. I'm not sure sure how feasible this is. We still need an on screen QWindow to receive input, resize, and hide/show events which would need to be redirected to the offscreen QQuickWindow. As far as I can tell, the only way we might be able to do that is with a QOpenGLWindow which shares a QOpenGLContext with the QQuickWindow, so we'd be bound to OpenGL and couldn't take advantage of the other RHI backends.
-
Hi,
Sorry I cannot answer your questions directly (though the subject is interesting).
You might want to bring your use case on the interest mailing list. You'll find there the RHI developers/maintainers.
-
I also agree this is highly interesting!
If you learn more on any mailing list, please post a link here to the discussion. I'd love to hear the conclusions.
-
Hi,
Sorry I cannot answer your questions directly (though the subject is interesting).
You might want to bring your use case on the interest mailing list. You'll find there the RHI developers/maintainers.
-
It's not an excuse but do not forget we are in the Hollidays season so things might be a bit slower.
-
@Be-ing thanks for the update! I was actually going to come back and ask about this thread next week, because it has stuck in my mind.
I've been thinking about this part of your quandary/inquiry:
@Be-ing said in determing graphics frame swap time when rendering in Qt 6:
This still leaves open the question of how to determine when the frame being rendered will be swapped to the screen. If I understand correctly, either the application needs to be able to control the swap time or we need a guarantee from Qt that swaps will occur at a steady, predictable time.
I'm definitely not as immersed in your project as you are. I probably haven't wrapped my head around the entirety of the problem.
But nonetheless...
I'm trying to imagine a way where you get unpredictably-timed swaps, and nevertheless manage to cope. I guess I would be introducing a third requirement to your "either... or" above. I would say "either the app needs to control swap time, or the swaps are predictable, or we can at least discover and monitor ('know') when all past swaps took place."
I'm thinking that if you can track past swap history, then you can dynamically adjust your rendering to match what you predict the next swap-timepoint to be? Is that crazy? And/or you could try to adjust on the fly to "catch up" and slow down as needed?
I don't know, though...
The more I think about it, I wonder if this is one of those things where Qt is constrained due to being ultra-cross-platform. The time of swap is probably very platform-specific, and therefore hard to expose in an abstracted way in the cross-platform API classes.
-
for reference, that is the link to the interest mailing list thread: https://lists.qt-project.org/pipermail/interest/2020-December/036112.html
-
@Be-ing thanks for the update! I was actually going to come back and ask about this thread next week, because it has stuck in my mind.
I've been thinking about this part of your quandary/inquiry:
@Be-ing said in determing graphics frame swap time when rendering in Qt 6:
This still leaves open the question of how to determine when the frame being rendered will be swapped to the screen. If I understand correctly, either the application needs to be able to control the swap time or we need a guarantee from Qt that swaps will occur at a steady, predictable time.
I'm definitely not as immersed in your project as you are. I probably haven't wrapped my head around the entirety of the problem.
But nonetheless...
I'm trying to imagine a way where you get unpredictably-timed swaps, and nevertheless manage to cope. I guess I would be introducing a third requirement to your "either... or" above. I would say "either the app needs to control swap time, or the swaps are predictable, or we can at least discover and monitor ('know') when all past swaps took place."
I'm thinking that if you can track past swap history, then you can dynamically adjust your rendering to match what you predict the next swap-timepoint to be? Is that crazy? And/or you could try to adjust on the fly to "catch up" and slow down as needed?
I don't know, though...
The more I think about it, I wonder if this is one of those things where Qt is constrained due to being ultra-cross-platform. The time of swap is probably very platform-specific, and therefore hard to expose in an abstracted way in the cross-platform API classes.
@KH-219Design said in determing graphics frame swap time when rendering in Qt 6:
I'm trying to imagine a way where you get unpredictably-timed swaps, and nevertheless manage to cope.
Yeah, I think we'll have to give this a try and see how it works. Who knows, the rendering time might be steady enough that it works okay. Or maybe we have a major misconception of what the problem is.
I managed to decouple the application logic from QWidgets and get a proof-of-concept QML GUI with a single Slider controlling the backend. But it will likely be a while before we get to experimenting with approaches to this problem especially considering Qt6 is not entirely source compatible with Qt5.
The more I think about it, I wonder if this is one of those things where Qt is constrained due to being ultra-cross-platform. The time of swap is probably very platform-specific, and therefore hard to expose in an abstracted way in the cross-platform API classes.
Perhaps. FWIW, the API for the application to trigger a swap on its own timing was removed before RHI. It was removed with QOpenGLWidget.
-
Stepping back from the specifics of the application, the general question is: How to render a smooth animation representing the value of a continuously changing variable (the position in the audio track) that can move in either direction at any time at any velocity and acceleration? Perhaps we need a PID controller?
