GLError on OSX With Qt 5.7 and Qt 5.8
When i compile OpenFlipper on OSX using Qt 5.7 or Qt 5.8 i get GLErrors when i add geometry to an empty scene. E.G. add a cube to a freshly started OpenFlipper.
If this is caused by the QPainter, which is indicated by my preliminary tests, i recommend reimplenting the QPainter. This way we might be able to provide CoreProfile compatibility with Qt Versions older than 5.9 and fix this issue at the same time.
The GLErrors occur after calling _painter->beginNativeCalls(); in QtGLGraphicsScene.cc drawBackground function
i am still not sure why as the only changes i see so far are the creation of a vao and binding respective buffers / unbinding those. a further look inside the painter at runtime might provide more insights, but that requires a debug build of qt and a working debugger on osx.
I am freezing this one for now, because i cannot start the debugger on OSX. @moebius If you authorise me to use a debugger on OSX i will resume work on this ticket, until then i am unable to investigate this further
So i have traced the glCall, but unfortunately i can't get a fix on the exact call, that causes the GLError, because when the profiler is running, i get a segfault.
However the glcallstack (attached)glCallstack.txt indicates, that the problem is caused by the resetGLState function of QGL2PaintEngineEx i looked at the differences between qt 5.8 and 5.9 and found a different ordering of the calls
d->lastTextureUsed = GLuint(-1); d->dirtyStencilRegion = QRect(0, 0, d->width, d->height); d->resetGLState(); d->shaderManager->setDirty(); d->needsSync = true; }
vs Qt 5.8
d->resetGLState(); // We don't know what texture units and textures the native painting // will activate and bind, so we can't assume anything when we return // from the native painting. d->lastTextureUnitUsed = QT_UNKNOWN_TEXTURE_UNIT; d->lastTextureUsed = GLuint(-1); d->dirtyStencilRegion = QRect(0, 0, d->width, d->height); d->shaderManager->setDirty(); d->needsSync = true; }
However the callstack is from Qt version 5.7 so i am going to check on this one tomorrow, but it seems like there is no way to prevent these GLErrors without patching the Qt versions 5.7 and 5.8