2017-06-21 15:33 GMT+02:00 Sean Harmer <s...@theharmers.co.uk>: > > > On 21/06/2017 14:16, Elvis Stansvik wrote: >> >> 2017-06-21 14:23 GMT+02:00 Viktor Engelmann <viktor.engelm...@qt.io>: >>> >>> On 21.06.2017 13:22, Elvis Stansvik wrote: >>>> >>>> ... >>>> However, I was hesitant to create a Qt bug report as I'm not at all >>>> sure yet that it's a Qt problem. There's still a possibility that it's >>>> a bug in the VTK rendering engine (though it does work when VTK is >>>> configured to use GLEW). >>> >>> >>> I actually guess it's a driver issue, but it would be nice to have a >>> dedicated bug report anyways, so we'd have a central point for tracking >>> the knowledge on the issue (at least, we could mark said bug reports as >>> duplicates of the new one, improving our statistics ;-) ) >> >> >> Alright. I'll make a report then. >> >> But just to be clear, the same VTK test case works fine on the same >> machine when running with "plain" VTK classes, where the rendering is >> set up using GLEW. It is only when running the test case with >> QVTKOpenGLWidget (which derives QOpenGLWidget) that the problem >> occurs. >> >> So I'm not sure it's a driver issue, or rather: If it is a driver >> issue, it must be one that manifests itself only when using >> QOpenGLWidget. > > > Note that QOpenGLWidget uses an internal FBO to enable it to composite other > widget content. This is accessed via the defaultFramebuffer() function. > Could it be that you rendering code is directly using id=0 for the default > framebuffer, which is not the case within QOGLWidget? > > If in doubt, run your pure VTK test case and QT test case through apitrace > and compare.
Thanks for the pointer Sean. I dug around, and VTK is blitting to QOpenGLWidget's default framebuffer object (defaultFramebufferObject()): https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/QVTKOpenGLWidget.cxx#L437-451 (I've verified that this section of code is executed.) I should perhaps clarify: This is only about volume rendering, other types of VTK rendering works fine (e.g. lines, charts, polygonal meshes et.c.). So the context is created fine, OpenGL rendering works, but the volume rendering (which I believe VTK is doing with float textures) breaks when switching to using QVTKOpenGLWidget. For the interested, VTKs volume rendering code is mostly in vtkOpenGLGPUVolumeRayCastMapper [1]. Elvis [1] https://gitlab.kitware.com/vtk/vtk/blob/master/Rendering/VolumeOpenGL2/vtkOpenGLGPUVolumeRayCastMapper.cxx > > Cheers, > > Sean > >> >>> >>>> ... >>>> The problem only seem to occur on Windows. It's working fine on my own >>>> Kubuntu 16.04 laptop (HD 4400 GPU). >>> >>> yes, our bug reports also only affect windows (mostly 32 bit windows 7) >> >> >> Okay. My test system is Windows 7 as well (with latest available Intel >> driver), although others on the vtk-developers list could reproduce on >> Windows 8.1. >> >> Elvis >> >>> >>> -- >>> >>> Viktor Engelmann >>> Software Engineer >>> >>> The Qt Company GmbH >>> Rudower Chaussee 13 >>> D-12489 Berlin >>> viktor.engelm...@qt.io >>> +49 151 26784521 >>> http://qt.io >>> >>> Geschäftsführer: Mika Pälsi, >>> Juha Varelius, Mika Harjuaho >>> Sitz der Gesellschaft: Berlin, >>> Registergericht: Amtsgericht >>> Charlottenburg, HRB 144331 B >>> >>> The Future is Written with Qt >>> www.qtworldsummit.com >>> >>> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
