Replace OpenGL drawing code by QML #193
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is much more performant than drawing a QPolygonF with a Shape+PathPolyline.
The previous version was based on TypeError, which could be many more things than a parameter count mismatch.
They are not used anymore, usages have been moved to qml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this pull request we replace the existing usages of handmade OpenGL by QML.
OpenGL was used in the Scope, Long Levels and Frequency Spectrum to achieve sufficient display performance. Unfortunately this has 2 downsides.
First OpenGL is low level, and does not ship with layout and composition features. Implementing the Friture graphs requires significant efforts. QML solves this by providing a high level scenegraph with powerful layout/anchoring abstractions. Also, having the view in QML and the backend code in Python provides a nice separation of concerns. QML bindings together with signals provide an easy way to update the screen at the relevant times.
Second, OpenGL is not straightforward to setup in a way that works everywhere. We believe this is solved too because Qt itself takes charge of configuring OpenGL (or other backends with Qt6). We hope that this will make it easier to run Friture on MacOS in particular.
The signal curves themselves are implemented as custom QQuickItem's. Numpy arrays can be efficiently copied to the vertex data of the QQuickItem. Performance is not lost there, since this is similar to what we were doing with PyOpenGL.
As part of the migration, we remove the "rebinning" code that was meant to reduce the amount of points sent to display. The new QQuickItem don't seem to need this anymore. Local testing shows that even without the "rebinning" step, the load is lower than with the previous code.
Visual changes are minor.