wglwidget: thin layer on top of qglwidget or qopenglwindow based widget #10959
Conversation
m0dB
changed the title
| /// deferred until Qt calls QGLWidget::initializeGL and cannot be done in the | ||
| /// GLWaveformWidgetAbstract is a WaveformWidgetAbstract & WGLWidget. It may | ||
| /// have a GLWaveformRenderer member which requires initialization that must be | ||
| /// deferred until Qt calls WGLWidget::initializeGL and cannot be done in the |
There was a problem hiding this comment.
Is this comment correct now or calls QT QGLWidget::initializeGL? This sentence is anyway weird because QT does not call magically something.
There was a problem hiding this comment.
I will need to investigate this. But there were several widgets that derived from QGLWidget + WaveformWidgetAbstract, and other widgets that derived from GLWaveformWidgetAbstract, which derived from QGLWidget + WaveformWidgetAbstract, which made no sense to me. The only difference between the two approaches was this additional GLWaveformRenderer member in GLWaveformWidgetAbstract and how it is called from initializeGL.
There was a problem hiding this comment.
I will have another look to understand the intention and try to improve the comment or maybe get rid of the construction altogether if i think it's not needed.
There was a problem hiding this comment.
I will move the wglwidgetqwidget.cpp file in CMakeLists.txt so it's not added when building with Qt6.
|
Still draft, there are some more changes I want to include. |
m0dB
force-pushed
the
wglwidget
branch
3 times, most recently
from
176b279
to
d243084
Compare
m0dB
changed the title
|
@daschuer in the end I included my QOpenGLWindow based WGLWidget in this PR. The only thing remaining is that I think this should use a buildenv with Qt 5.15.x. Are you planning to do that for main? |
…wheel event to wglwidget from openglwindow
|
This PR is marked as stale because it has been open 90 days with no activity. |
github-actions
bot
added
the
stale
Is this really neccessary to merge this PR? Shouldn't it work with the actual buildenv as well? |
|
You can find an QT 5.15.7 macOS environment here: This should not be a requirement for merging. |
github-actions
bot
removed
the
stale
|
This PR is marked as stale because it has been open 90 days with no activity. |
github-actions
bot
added
the
stale
|
I think this can be closed too? |
|
closed as superseded by #10989 |
This PR replaces the use of QGLWidget with a new class WGLWidget.
The new cmake option QOPENGL determines how WGLWidget is implemented:
with QOPENGL=OFF: WGLWidget is a class derived from QGLWidget, with code that was duplicated in derived classes such as WSpinny, WVuMeterGL, the waveform widget and in waveform widget factory, moved WGLWidget methods. This is a refactoring that should behave exactly the same as before.
with QOPENGL=ON: WGLWidget is class derived from QWidget that has an container widget that contains an QOpenGLWindow. As far as I have tested, on macOS rendering with QOpenGLWindow is significantly faster than QGLWidget.
The two implementations use the same API, wit the intention of keeping all use of these classes and the derived classes identical, independent of the implementation used. There are some exceptions, where implementation specific code is needed (e.g. forwarding events to the WWaveformViewer), this is done inside #ifdef MIXXX_USE_QOPENGL blocks.
In addition to this, all use of either the old Qt QGL.. or the new Qt QOpenGL.. classes is also handled with the MIXXX_USE_QOPENGL preprocessor define (defined by cmake)
Finally, I added another WVuMeter implementation, one that uses QOpenGL code and uses textures and shaders to render the pixmaps instead of QPainter.
Note that I have a third WGLWidget implementation, which uses QOpenGLWidget, but on macOS this has the same problems as QGLWidget (bad framerate, laggy interaction), so I can't really test it. It would be good if a linux or windows dev code take over. This will allow us to completely replace the deprecated QGL... classes with QOpenGL... classes.