[Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
elvstone at gmail.com
Wed Jun 21 16:47:23 CEST 2017
2017-06-21 15:33 GMT+02:00 Sean Harmer <sh at theharmers.co.uk>:
> On 21/06/2017 14:16, Elvis Stansvik wrote:
>> 2017-06-21 14:23 GMT+02:00 Viktor Engelmann <viktor.engelmann at 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
>> 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
> 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
(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
>>>> 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.
>>> Viktor Engelmann
>>> Software Engineer
>>> The Qt Company GmbH
>>> Rudower Chaussee 13
>>> D-12489 Berlin
>>> Viktor.Engelmann at qt.io
>>> +49 151 26784521
>>> 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
>> Interest mailing list
>> Interest at qt-project.org
> Interest mailing list
> Interest at qt-project.org
More information about the Interest