Re: [Interest] creating a binary .rcc version of a series of Freedesktop icon themes linked through inheritance
On Wednesday, 21 June 2017 11:36:08 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > You don't need rcc files inheriting from each other. Just link more than > > one into your application. They just have to use different file paths. > But then you have to register each one individually with > QResource::registerResource(), no? If you compile them with qrc, then they register themselves. Another option is to link them together into a single .so that you can load via QLibrary or QPluginLoader. If you're supplying external files, then you need to load each one independently. > To be more explicit: I'm looking for a solution that'll work with the rcc > icon theme support built into the KF5 KIconThemes framework. > (https://cgit.kde.org/kiconthemes.git/tree/src/kicontheme.cpp#n48) Sorry, I don't know the API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] creating a binary .rcc version of a series of Freedesktop icon themes linked through inheritance
Thiago Macieira wrote: > You don't need rcc files inheriting from each other. Just link more than one > into your application. They just have to use different file paths. But then you have to register each one individually with QResource::registerResource(), no? To be more explicit: I'm looking for a solution that'll work with the rcc icon theme support built into the KF5 KIconThemes framework. (https://cgit.kde.org/kiconthemes.git/tree/src/kicontheme.cpp#n48) R ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [Releasing] First Qt 5.9.1 snapshot available
-Original Message- From: Simon Hausmann [mailto:simon.hausm...@qt.io] Sent: Wednesday, June 21, 2017 08:47 To: Bullinger, Julius Cc: interest@qt-project.org; releas...@qt-project.org Subject: Re: [Releasing] First Qt 5.9.1 snapshot available > Hi, > > If my memory serves me right then it's a little magic :) > > You select the qqc in the installer and it will show - as version- the latest > Qt version that a build is > available for (like even a 5.9 snapshot). Behind the scenes however it would > install binaries of the > compiler for all Qt versions that you have selected, into the respective > installation directories. > > The compiler is strictly tied to the Qt version, so a binary from 5.9 cannot > be used with 5.7. However > the installer should have placed a 5.7 compatible version into your Qt 5.7 > directory if you have > selected 5.8 and qqc. I see, thanks for the explanation! Is this documented anywhere? If not, it should perhaps be. ;) Best regards, Julius Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
2017-06-21 15:33 GMT+02:00 Sean Harmer : > > > On 21/06/2017 14:16, Elvis Stansvik wrote: >> >> 2017-06-21 14:23 GMT+02:00 Viktor Engelmann : >>> >>> 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
Re: [Interest] creating a binary .rcc version of a series of Freedesktop icon themes linked through inheritance
On Wednesday, 21 June 2017 02:18:23 PDT René J.V. Bertin wrote: > Hi, > > I'd like to create a single binary .rcc resource from a total of 4 > Freedesktop icon themes that are linked through inheritance. Merging the > actual directories is straightforward, but creating a merged index.theme > file isn't . > > Does anyone know of a tool to assist in that part of the merge or is there > rcc functionality I'm overlooking that allows a .rcc file to declare a > dependency on another .rcc file, such that the application needs only > register that single "toplevel" rcc file? You don't need rcc files inheriting from each other. Just link more than one into your application. They just have to use different file paths. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
On 21/06/2017 14:16, Elvis Stansvik wrote: 2017-06-21 14:23 GMT+02:00 Viktor Engelmann : 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. 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
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
2017-06-21 14:23 GMT+02:00 Viktor Engelmann : > 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. > >> ... >> 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] qmake replaces 'debug'/'release' in DESTDIR
Hi everyone, I have encountered something unexpected with qmake on Windows. If DESTDIR contains either "release" or "debug", qmake will replace it with the one matching the actual build configuration. For instance if I have: "DESTDIR = foo/release/bar" and I run: "qmake CONFIG+=debug" the actual DESTDIR in the generated Makefile will be "foo/debug/bar". As far as I know it looks like it is caused by: qtbase/mkspecs/features/exclusive_builds_post.prf Also it doesn't happen anymore if I do not do and "debug_and_release" build on Windows and it never happens on Linux (with or without "debug_and_release"). It looks like a bug to me. Is this behavior expected for some use cases? Regards Benjamin Terrier ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
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 ;-) ) > ... > 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) -- 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
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
2017-06-21 12:28 GMT+02:00 Viktor Engelmann : > Hello Elvis, > > Haswell and Ivy Bridge indeed ring a bell here. We have a lot of > WebEngine bug reports that affect these GPUs only. > Can you create a bug report please? Alright, good to know that I'm not completely alone. 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). Perhaps I should try to make a pure Qt test case first that shows the problem. If I fail, then maybe that would be an indication that it's something in VTKs rendering engine that is at fault. > > OpenGL 3.2 context raises an eyebrow here, because just yesterday I have > seen a qtdiag output from a Debian 7 machine (2013 isn't THAT long ago) > with mesa 8.0.5, which only supports OpenGL 3.0. OK. The machine that I'm testing on is a Lenovo Thinkpad E540 with a HD 4600 GPU. The GPU is supposed to have 100% support for 3.2 core profile (verified this using "OpenGL Extension Viewer", http://realtech-vr.com/admin/glview), and I've verified that VTK does indeed get a correctly versioned context from Qt. The problem only seem to occur on Windows. It's working fine on my own Kubuntu 16.04 laptop (HD 4400 GPU). Elvis > > Kind regards > > > On 21.06.2017 11:38, Elvis Stansvik wrote: >> This may or may not be a Qt issue. >> >> I'm trying to help the VTK folks narrow down a problem with their new >> QVTKOpenGLWidget, which is a newly-introduced QOpenGLWidget-based >> class for letting VTK render into a QOpenGLWidget. >> >> The problem manifests itself as volume renderings not showing up on >> Windows machines with Ivy Bridge (e.g HD4000) and Haswell (e.g. >> HD4600) Intel GPUs when using the new class. VTKs volume rendering is >> done using float textures. >> >> Volume renderings works fine on the same machines when using "plain" >> VTK. This is when VTK itself sets up the OpenGL context (using GLEW I >> believe), but apart from that, the rendering pipeline is exactly the >> same I think. This is what leads me to believe that the issue is >> something specific to QOpenGLWidget, or to how VTK uses it. >> >> VTK requests a OpenGL 3.2 core context, and through some debugging, >> I've verified that VTK is actually getting the context that it is >> requesting. >> >> The issue is reported by me, here at VTKs GitLab: >> >>https://gitlab.kitware.com/vtk/vtk/issues/17058 >> >> The report contains some more information, such as the generated >> fragment shader that VTKs volume rendering backend is using, and a GL >> report from the problematic machine. >> >> Does this specific issue (float texture rendering not showing up on >> these semi-old Intel GPUs) ring a bell to anyone else? >> >> Many thanks for any tips/pointers/leads on how to debug this. >> >> I'm really interested in getting this issue in VTK fixed, since >> laptops with these GPUs are quite common. It's also affecting recent >> versions of ParaView, which has (just like me) recently ported to the >> new QVTKOpenGLWidget. >> >> Elvis >> ___ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest > > -- > > 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
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
Hello Elvis, Haswell and Ivy Bridge indeed ring a bell here. We have a lot of WebEngine bug reports that affect these GPUs only. Can you create a bug report please? OpenGL 3.2 context raises an eyebrow here, because just yesterday I have seen a qtdiag output from a Debian 7 machine (2013 isn't THAT long ago) with mesa 8.0.5, which only supports OpenGL 3.0. Kind regards On 21.06.2017 11:38, Elvis Stansvik wrote: > This may or may not be a Qt issue. > > I'm trying to help the VTK folks narrow down a problem with their new > QVTKOpenGLWidget, which is a newly-introduced QOpenGLWidget-based > class for letting VTK render into a QOpenGLWidget. > > The problem manifests itself as volume renderings not showing up on > Windows machines with Ivy Bridge (e.g HD4000) and Haswell (e.g. > HD4600) Intel GPUs when using the new class. VTKs volume rendering is > done using float textures. > > Volume renderings works fine on the same machines when using "plain" > VTK. This is when VTK itself sets up the OpenGL context (using GLEW I > believe), but apart from that, the rendering pipeline is exactly the > same I think. This is what leads me to believe that the issue is > something specific to QOpenGLWidget, or to how VTK uses it. > > VTK requests a OpenGL 3.2 core context, and through some debugging, > I've verified that VTK is actually getting the context that it is > requesting. > > The issue is reported by me, here at VTKs GitLab: > >https://gitlab.kitware.com/vtk/vtk/issues/17058 > > The report contains some more information, such as the generated > fragment shader that VTKs volume rendering backend is using, and a GL > report from the problematic machine. > > Does this specific issue (float texture rendering not showing up on > these semi-old Intel GPUs) ring a bell to anyone else? > > Many thanks for any tips/pointers/leads on how to debug this. > > I'm really interested in getting this issue in VTK fixed, since > laptops with these GPUs are quite common. It's also affecting recent > versions of ParaView, which has (just like me) recently ported to the > new QVTKOpenGLWidget. > > Elvis > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest -- 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
Re: [Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
2017-06-21 11:38 GMT+02:00 Elvis Stansvik : > This may or may not be a Qt issue. > > I'm trying to help the VTK folks narrow down a problem with their new > QVTKOpenGLWidget, which is a newly-introduced QOpenGLWidget-based > class for letting VTK render into a QOpenGLWidget. > > The problem manifests itself as volume renderings not showing up on > Windows machines with Ivy Bridge (e.g HD4000) and Haswell (e.g. > HD4600) Intel GPUs when using the new class. VTKs volume rendering is > done using float textures. > > Volume renderings works fine on the same machines when using "plain" > VTK. This is when VTK itself sets up the OpenGL context (using GLEW I > believe), but apart from that, the rendering pipeline is exactly the > same I think. This is what leads me to believe that the issue is > something specific to QOpenGLWidget, or to how VTK uses it. I should clarify: I mean the rendering pipeline for volume rendering in VTK is exactly the same when using "plain" (non-Qt) VTK (which works), as when using QVTKOpenGLWidget. The only difference (AFAIK) is in how the OpenGL context is set up (GLEW or QOpenGLWidget). (The VTK issue I linked also has a minimal VTK testcase I wrote, where you can switch between using QVTKOpenGLWidget or plain VTK rendering by passing or not passing a command line parameter). Elvis > > VTK requests a OpenGL 3.2 core context, and through some debugging, > I've verified that VTK is actually getting the context that it is > requesting. > > The issue is reported by me, here at VTKs GitLab: > >https://gitlab.kitware.com/vtk/vtk/issues/17058 > > The report contains some more information, such as the generated > fragment shader that VTKs volume rendering backend is using, and a GL > report from the problematic machine. > > Does this specific issue (float texture rendering not showing up on > these semi-old Intel GPUs) ring a bell to anyone else? > > Many thanks for any tips/pointers/leads on how to debug this. > > I'm really interested in getting this issue in VTK fixed, since > laptops with these GPUs are quite common. It's also affecting recent > versions of ParaView, which has (just like me) recently ported to the > new QVTKOpenGLWidget. > > Elvis ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [Releasing] First Qt 5.9.1 snapshot available
>> >> >>From: Releasing on >>behalf of Simon Hausmann >>Sent: Wednesday, June 21, 2017 9:47 AM >>To: Bullinger, Julius >>Cc: releas...@qt-project.org; interest@qt-project.org >>Subject: Re: [Releasing] First Qt 5.9.1 snapshot available >> >>Hi, >> >>If my memory serves me right then it's a little magic :) >> >>You select the qqc in the installer and it will show - as version- the latest >>Qt version that a build is available for (like even a 5.9 snapshot). Behind >>the scenes however it would install binaries of the compiler for all >>Qt >>versions that you have selected, into the respective installation directories. Yes, you remembered it right ;) br, Jani ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Problem with float texture rendering in QOpenGLWidget on Ivy Bridge/Haswell Intel GPUs on Windows
This may or may not be a Qt issue. I'm trying to help the VTK folks narrow down a problem with their new QVTKOpenGLWidget, which is a newly-introduced QOpenGLWidget-based class for letting VTK render into a QOpenGLWidget. The problem manifests itself as volume renderings not showing up on Windows machines with Ivy Bridge (e.g HD4000) and Haswell (e.g. HD4600) Intel GPUs when using the new class. VTKs volume rendering is done using float textures. Volume renderings works fine on the same machines when using "plain" VTK. This is when VTK itself sets up the OpenGL context (using GLEW I believe), but apart from that, the rendering pipeline is exactly the same I think. This is what leads me to believe that the issue is something specific to QOpenGLWidget, or to how VTK uses it. VTK requests a OpenGL 3.2 core context, and through some debugging, I've verified that VTK is actually getting the context that it is requesting. The issue is reported by me, here at VTKs GitLab: https://gitlab.kitware.com/vtk/vtk/issues/17058 The report contains some more information, such as the generated fragment shader that VTKs volume rendering backend is using, and a GL report from the problematic machine. Does this specific issue (float texture rendering not showing up on these semi-old Intel GPUs) ring a bell to anyone else? Many thanks for any tips/pointers/leads on how to debug this. I'm really interested in getting this issue in VTK fixed, since laptops with these GPUs are quite common. It's also affecting recent versions of ParaView, which has (just like me) recently ported to the new QVTKOpenGLWidget. Elvis ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] creating a binary .rcc version of a series of Freedesktop icon themes linked through inheritance
Hi, I'd like to create a single binary .rcc resource from a total of 4 Freedesktop icon themes that are linked through inheritance. Merging the actual directories is straightforward, but creating a merged index.theme file isn't . Does anyone know of a tool to assist in that part of the merge or is there rcc functionality I'm overlooking that allows a .rcc file to declare a dependency on another .rcc file, such that the application needs only register that single "toplevel" rcc file? Thanks, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
