From thewantonmate at yahoo.com Mon Aug 21 10:29:57 2017 From: thewantonmate at yahoo.com (Matt) Date: Mon, 21 Aug 2017 08:29:57 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> Message-ID: <1112359580.1778161.1503304197183@mail.yahoo.com> Hello, this is regarding the following forum post: Qt5: can WebGL work with ANGLE on Windows via QtWebEngine? where it was suggested that we send a message to this mailing list for more authoritative answers. tl;dr: We're not able to get WebGL pages viewed with QtWebEngine (5.9.1 or 5.10.0) working on a Windows 10 Surface Pro 3, which uses Intel HD 5000 graphics, and would like to know whether it's possible and how to do so. We can get WebGL partially working by (1) using desktop OpenGL via Qt::AA_UseDesktopOpenGL, (2) applying a patch to web_engine_context.cpp that passes --disable-es3-gl-context, and (3) passing --ignore-gpu-blacklist on the command line. However, something is still wonky with texturing and/or lighting and some WebGL samples do not look correct - geometry is all black. If we pass similar flags to Chrome browser (including --use-gl=deskop, --ignore-gpu-blacklist, and --disable-es3-gl-context), we get the same behavior, which suggests that perhaps the underlying Chromium libraries do not work properly with this hardware. However, by default, Chrome browser uses ANGLE and everything appears perfectly, so we thought that we could achieve similar performance in Qt. But when we try to use ANGLE in QtWebEngine via Qt::AA_UseOpenGLES, we cannot get WebGL working at all on any computer we've tried (two are NVIDIA/Optimus and one is Intel only). The chrome://gpu page indicates software-only capabilities, since apparently QtWebEngine is passing the --disable-gpu switch when GLES is enabled. When we try to view pages with WebGL content, we get the standard 'WebGL is disabled' message. Is this the intended behavior? Can ANGLE not work with QtWebEngine to display WebGL content as it does in Chrome browser? Is there _any_ way to get WebGL working properly on our hardware? We'd be happy to provide any additional detail or information that we've omitted here. Thanks in advance for any help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Mon Aug 21 10:45:15 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 21 Aug 2017 08:45:15 +0000 Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1112359580.1778161.1503304197183@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> Message-ID: <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> Hello, On 21. Aug 2017, at 10:29, Matt via QtWebEngine > wrote: Hello, this is regarding the following forum post: Qt5: can WebGL work with ANGLE on Windows via QtWebEngine? where it was suggested that we send a message to this mailing list for more authoritative answers. tl;dr: We're not able to get WebGL pages viewed with QtWebEngine (5.9.1 or 5.10.0) working on a Windows 10 Surface Pro 3, which uses Intel HD 5000 graphics, and would like to know whether it's possible and how to do so. We can get WebGL partially working by (1) using desktop OpenGL via Qt::AA_UseDesktopOpenGL, (2) applying a patch to web_engine_context.cpp that passes --disable-es3-gl-context, and (3) passing --ignore-gpu-blacklist on the command line. However, something is still wonky with texturing and/or lighting and some WebGL samples do not look correct - geometry is all black. If we pass similar flags to Chrome browser (including --use-gl=deskop, --ignore-gpu-blacklist, and --disable-es3-gl-context), we get the same behavior, which suggests that perhaps the underlying Chromium libraries do not work properly with this hardware. However, by default, Chrome browser uses ANGLE and everything appears perfectly, so we thought that we could achieve similar performance in Qt. But when we try to use ANGLE in QtWebEngine via Qt::AA_UseOpenGLES, we cannot get WebGL working at all on any computer we've tried (two are NVIDIA/Optimus and one is Intel only). The chrome://gpu page indicates software-only capabilities, since apparently QtWebEngine is passing the --disable-gpu switch when GLES is enabled. When we try to view pages with WebGL content, we get the standard 'WebGL is disabled' message. Is this the intended behavior? Can ANGLE not work with QtWebEngine to display WebGL content as it does in Chrome browser? Is there _any_ way to get WebGL working properly on our hardware? This is intended behavior. WebGL will not work if ANGLE is being used by Qt. ANGLE does not support multi-threaded access to GL contexts, and that is a requirement for the current Qt Quick Scene Graph implementation used by WebEngine. WebEngine detects that ANGLE is being used, and passes the --disable-gpu to the renderer - to switch to software rendering, and WebGL does not currently work with software rendering. Thus the only setup that can work with WebGL at the moment is to use Desktop GL, which depends on the quality of the GPU GL drivers. You can take a look at https://bugreports.qt.io/browse/QTBUG-55604 , and try passing --disable_chromium_framebuffer_multisample together with the the other flags that you mentioned, and see if that helps. We'd be happy to provide any additional detail or information that we've omitted here. Thanks in advance for any help! _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmy at keba.com Mon Aug 21 16:52:47 2017 From: bmy at keba.com (bmy Bachmayr Hannes) Date: Mon, 21 Aug 2017 14:52:47 +0000 Subject: [Qtwebengine] QT5.9.1 QtWebEngine Cross Compile - i.MX6 Message-ID: Hello gents, I am trying to compile QT5.9.1 for my i.MX6 target and I am having problems in getting it build. I have no problems in cross compiling QT for my target without the QtWebEngine support. Also a cross build of Qt 5.7.1 works without any compile errors or issues. But starting with Qt 5.8.0 up to 5.9.1 cross building the QtWebKit doesn't work anymore. Here is my configuration and the error message I get. Any help appreciated. Thanks in advance. Error Message: make[4]: Entering directory '/opt/armv7/tmp/qtwebengine/src/core' make[4]: Nothing to be done for 'install'. make[4]: Leaving directory '/opt/armv7/tmp/qtwebengine/src/core' cd api/ && ( test -e Makefile.core_api || /opt/armv7/tmp/qtbase/bin/qmake -o Makefile.core_api /opt/armv7/src/qt-everywhere-opensource-src-5.9.1/qtwebengine/src/core/api/core_api.pro ) && make -f Makefile.core_api install make[4]: Entering directory '/opt/armv7/tmp/qtwebengine/src/core/api' make[4]: Nothing to be done for 'install'. make[4]: Leaving directory '/opt/armv7/tmp/qtwebengine/src/core/api' ( test -e Makefile.core_module || /opt/armv7/tmp/qtbase/bin/qmake -o Makefile.core_module /opt/armv7/src/qt-everywhere-opensource-src-5.9.1/qtwebengine/src/core/core_module.pro ) && make -f Makefile.core_module install make[4]: Entering directory '/opt/armv7/tmp/qtwebengine/src/core' perl /opt/armv7/src/qt-everywhere-opensource-src-5.9.1/qtbase/mkspecs/features/data/unix/findclasslist.pl < QtWebEngineCore.version.in > QtWebEngineCore.version make[4]: *** No rule to make target '/opt/armv7/tmp/qtwebengine/src/core/Release/QtWebEngineCore.stamp', needed by '../../lib/libQt5WebEngineCore.so.5.9.1'. Stop. make[4]: Leaving directory '/opt/armv7/tmp/qtwebengine/src/core' Makefile:130: recipe for target 'sub-core_module-pro-install_subtargets' failed make[3]: *** [sub-core_module-pro-install_subtargets] Error 2 make[3]: Leaving directory '/opt/armv7/tmp/qtwebengine/src/core' Makefile:89: recipe for target 'sub-core-install_subtargets' failed make[2]: *** [sub-core-install_subtargets] Error 2 make[2]: Leaving directory '/opt/armv7/tmp/qtwebengine/src' Makefile:58: recipe for target 'sub-src-install_subtargets' failed make[1]: *** [sub-src-install_subtargets] Error 2 make[1]: Leaving directory '/opt/armv7/tmp/qtwebengine' Makefile:957: recipe for target 'module-qtwebengine-install_subtargets' failed make: *** [module-qtwebengine-install_subtargets] Error 2 Build-Configuration: export PATH=$BIN_DIR/gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf/bin:$PATH:; export PKG_CONFIG_LIBDIR=$ROOTFS_DIR/usr/lib/pkgconfig:$ROOTFS_DIR/usr/share/pkgconfig:$ROOTFS_DIR/usr/lib/arm-linux-gnueabihf/pkgconfig; export PKG_CONFIG_SYSROOT_DIR=$ROOTFS; $SRC_DIR/qt-everywhere-opensource-src-5.9.1/configure \ -confirm-license \ -release \ -shared \ -opensource \ -prefix /usr/local/ \ -bindir /usr/local/qt5/bin \ -libdir /usr/local/lib \ -headerdir /usr/local/include \ -datadir /usr/local/share/qt5 \ -archdatadir /usr/local/qt5 \ -plugindir /usr/local/qt5/plugins \ -importdir /usr/local/qt5/imports \ -translationdir /usr/local/share/qt5/translations \ -hostdatadir $TOOLS_DIR/share/qt5 \ -extprefix $DIST_DIR \ -hostprefix $TOOLS_DIR \ -xplatform linux-arm-gnueabihf-g++ \ -platform linux-g++ \ -sysroot $ROOTFS_DIR \ -no-pch \ -opengl es2 \ -skip qtwayland \ -skip qtwebkit \ -skip qtwebkit-examples \ -nomake examples \ -nomake tests \ -reduce-exports \ -make libs; make -j6; make install'; Freundliche Grüße/Best regards Hannes Bachmayr, DI Technical Sales Engineer HMI Vertriebsingenieur HMI KEBA AG Gewerbepark Urfahr 4041 Linz/Austria Phone: +43 732 7090-23191 Fax: +43 732 7090-63401 Mobile: +43 732 7090-73191 Firmenbuchgericht Linz FN 184376 t bmy at keba.com www.keba.com [facebook] [LinkedIn] [youtube] [g+] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 675 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 983 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1253 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 1201 bytes Desc: image004.png URL: From thewantonmate at yahoo.com Mon Aug 21 17:24:27 2017 From: thewantonmate at yahoo.com (Matt) Date: Mon, 21 Aug 2017 15:24:27 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> Message-ID: <1217385248.2007493.1503329067030@mail.yahoo.com> Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation.  This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Mon Aug 21 17:34:31 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 21 Aug 2017 15:34:31 +0000 Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1217385248.2007493.1503329067030@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> Message-ID: <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> On 21. Aug 2017, at 17:24, Matt via QtWebEngine > wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation. This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver. The flags are: --enable-logging -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewantonmate at yahoo.com Tue Aug 22 06:02:14 2017 From: thewantonmate at yahoo.com (Matt) Date: Tue, 22 Aug 2017 04:02:14 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> Message-ID: <1627822754.2502642.1503374534050@mail.yahoo.com> Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation.  This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver.  The flags are:  --enable-logging  -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Tue Aug 22 10:58:31 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Tue, 22 Aug 2017 08:58:31 +0000 Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1627822754.2502642.1503374534050@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> Message-ID: Afaik, the current status about using Mesa OpenGL is that WebGL won't work. Why is that so, I do not know. That would require investigation. On 22. Aug 2017, at 06:02, Matt via QtWebEngine > wrote: Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor > wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine > wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation. This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver. The flags are: --enable-logging -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Tue Aug 22 17:13:48 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Tue, 22 Aug 2017 15:13:48 +0000 Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> Message-ID: <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> I looked into it a bit, and it seems that there's some hope to make MESA llvmpipe work with WebEngine so that WebGL also works. I guess the performance would not be spectacular, but it's better than nothing. Stay tuned. On 22. Aug 2017, at 10:58, Alexandru Croitor > wrote: Afaik, the current status about using Mesa OpenGL is that WebGL won't work. Why is that so, I do not know. That would require investigation. On 22. Aug 2017, at 06:02, Matt via QtWebEngine > wrote: Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor > wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine > wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation. This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver. The flags are: --enable-logging -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewantonmate at yahoo.com Tue Aug 22 21:27:49 2017 From: thewantonmate at yahoo.com (Matt) Date: Tue, 22 Aug 2017 19:27:49 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> Message-ID: <1729977477.3051980.1503430069615@mail.yahoo.com> Will do, thanks. Getting correct functionality at the expense of performance is ok for our application. We grabbed pre-built mesa binaries and tried putting them in the same directory as our Qt app, but the app crashed immediately on startup. I'm sure we're missing something though, so we look forward to hearing back from you. On Tuesday, August 22, 2017, 11:13:54 AM EDT, Alexandru Croitor wrote: I looked into it a bit, and it seems that there's some hope to make MESA llvmpipe work with WebEngine so that WebGL also works. I guess the performance would not be spectacular, but it's better than nothing. Stay tuned. On 22. Aug 2017, at 10:58, Alexandru Croitor wrote: Afaik, the current status about using Mesa OpenGL is that WebGL won't work. Why is that so, I do not know. That would require investigation. On 22. Aug 2017, at 06:02, Matt via QtWebEngine wrote: Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation.  This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver.  The flags are:  --enable-logging  -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Wed Aug 23 12:13:08 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Wed, 23 Aug 2017 10:13:08 +0000 Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1729977477.3051980.1503430069615@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> <1729977477.3051980.1503430069615@mail.yahoo.com> Message-ID: <4E475D55-3D15-4E62-849E-8C9153FB8555@qt.io> You can try my set of patches at https://codereview.qt-project.org/#/c/203206/ and https://codereview.qt-project.org/#/c/203208/ applied to a 5.9 checkout. You also need to rename your mesa dll to opengl32sw.dll as described in http://doc.qt.io/qt-5/windows-requirements.html and place it in your application folder for instance (personally I put it into the ./lib folder of my installed Qt). Finally you need to set the Qt::AA_UseSoftwareOpenGL application attribute, and pass "--enable-webgl-software-rendering" to your WebEngine application. That should force the usage of the openglsw32.dll for Chromium and WebGL. On 22. Aug 2017, at 21:27, Matt via QtWebEngine > wrote: Will do, thanks. Getting correct functionality at the expense of performance is ok for our application. We grabbed pre-built mesa binaries and tried putting them in the same directory as our Qt app, but the app crashed immediately on startup. I'm sure we're missing something though, so we look forward to hearing back from you. On Tuesday, August 22, 2017, 11:13:54 AM EDT, Alexandru Croitor > wrote: I looked into it a bit, and it seems that there's some hope to make MESA llvmpipe work with WebEngine so that WebGL also works. I guess the performance would not be spectacular, but it's better than nothing. Stay tuned. On 22. Aug 2017, at 10:58, Alexandru Croitor > wrote: Afaik, the current status about using Mesa OpenGL is that WebGL won't work. Why is that so, I do not know. That would require investigation. On 22. Aug 2017, at 06:02, Matt via QtWebEngine > wrote: Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor > wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine > wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation. This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver. The flags are: --enable-logging -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewantonmate at yahoo.com Wed Aug 23 17:45:51 2017 From: thewantonmate at yahoo.com (Matt) Date: Wed, 23 Aug 2017 15:45:51 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <4E475D55-3D15-4E62-849E-8C9153FB8555@qt.io> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> <1729977477.3051980.1503430069615@mail.yahoo.com> <4E475D55-3D15-4E62-849E-8C9153FB8555@qt.io> Message-ID: <1661714034.673218.1503503151580@mail.yahoo.com> Fantastic, thank you! We will give it a try today and post the results. On Wednesday, August 23, 2017, 6:13:13 AM EDT, Alexandru Croitor wrote: You can try my set of patches at https://codereview.qt-project.org/#/c/203206/ and https://codereview.qt-project.org/#/c/203208/ applied to a 5.9 checkout.  You also need to rename your mesa dll to opengl32sw.dll as described in http://doc.qt.io/qt-5/windows-requirements.html and place it in your application folder for instance (personally I put it into the ./lib folder of my installed Qt).  Finally you need to set the Qt::AA_UseSoftwareOpenGL application attribute, and pass "--enable-webgl-software-rendering" to your WebEngine application. That should force the usage of the openglsw32.dll for Chromium and WebGL. On 22. Aug 2017, at 21:27, Matt via QtWebEngine wrote: Will do, thanks. Getting correct functionality at the expense of performance is ok for our application. We grabbed pre-built mesa binaries and tried putting them in the same directory as our Qt app, but the app crashed immediately on startup. I'm sure we're missing something though, so we look forward to hearing back from you. On Tuesday, August 22, 2017, 11:13:54 AM EDT, Alexandru Croitor wrote: I looked into it a bit, and it seems that there's some hope to make MESA llvmpipe work with WebEngine so that WebGL also works. I guess the performance would not be spectacular, but it's better than nothing. Stay tuned. On 22. Aug 2017, at 10:58, Alexandru Croitor wrote: Afaik, the current status about using Mesa OpenGL is that WebGL won't work. Why is that so, I do not know. That would require investigation. On 22. Aug 2017, at 06:02, Matt via QtWebEngine wrote: Ok. I didn't see my specific GPU called out in the blacklist but I suspect that the driver is the issue. I have the latest driver version (from a couple of months ago) but even if I uninstall it, presumably then using the default Microsoft opengl32.dll, I get the same behavior with black geometry. Since ANGLE is not an option, is it instead possible to use WebGL if I replace the system opengl32.dll with a mesa3d (software-only) version, still using Qt::AA_UseDesktopGL? Or perhaps by placing the mesa dlls in the same directory as my Qt app binary? On Monday, August 21, 2017, 11:34:35 AM EDT, Alexandru Croitor wrote: On 21. Aug 2017, at 17:24, Matt via QtWebEngine wrote: Hello and thank you very much for your response. We suspected as much (re: ANGLE + WebGL) from the code but it's good to get an official confirmation.  This is unfortunate for our project as we depend on WebGL web content, and while it does partially work with the mentioned flags, objects still show up black in some scenarios for some reason. The fact that Chrome browser exhibits the same behavior with desktop OpenGL does not bode well. We did see the bug report you mentioned and we did try the --disable_chromium_framebuffer_multisample flag, but unfortunately it doesn't help. Is there a way to perhaps debug our specific issue to at least see which WebGL calls are failing? Perhaps some additional flags might help? Any advice is greatly appreciated. Thanks once again! Usually with Intel GPUs the suspect is the GPU driver (you can search for the vendor and model id of your GPU card in the chromium blacklist files, there are a lot of Intel GPUs in that list). You can try passing the following command line arguments to the WebEngine application ( or Chromium, although something additional might be needed there) to enable verbose debugging. I can't think of anything else. Ut just might be that Chromium uses GL calls / techniques that are broken with the respective GPU driver.  The flags are:  --enable-logging  -v=9 _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewantonmate at yahoo.com Thu Aug 24 07:59:39 2017 From: thewantonmate at yahoo.com (Matt) Date: Thu, 24 Aug 2017 05:59:39 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <1661714034.673218.1503503151580@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> <1729977477.3051980.1503430069615@mail.yahoo.com> <4E475D55-3D15-4E62-849E-8C9153FB8555@qt.io> <1661714034.673218.1503503151580@mail.yahoo.com> Message-ID: <2031848025.1170424.1503554379260@mail.yahoo.com> Update: we spent a good deal of time today cloning the git repo and building Qt after applying the patches. We followed your instructions, adding the --enable-webgl-software-rendering flag and enabling Qt::AA_UseSoftwareOpenGL. We used the same pre-built mesa3d library as before, from here: pal1000/mesa-dist-win putting the dlls alongside our application binary and renaming to opengl32sw.dll. Unfortunately, the application crashed immediately on startup, just as it did before when we tried running mesa without the code patches. However, suspecting the mesa library itself, we then tried copying opengl32sw.dll from the official Qt 5.9.1 release binaries instead - and that worked! We are now able to render our webgl content properly within our Qt application thanks to your new feature! For what it's worth - before this change, our intent was to essentially trick our Qt app into thinking that a software-only OpenGL implementation was the system's desktop implementation, by either overwriting the operating system's opengl32.dll or placing the software opengl32.dll alongside our app. This didn't work at the time. However, once we found out that the mesa binaries we had downloaded didn't play nicely with Qt, we then tried another experiment: we built our application against the official downloaded Qt 5.9.1 release binaries, changed back to using Qt::AA_UseDesktopGL, and renamed opengl32sw.dll (from the Qt bin directory) back to opengl32.dll in our application directory, as we originally intended to do. This worked too! In any case, thank you once again for all your help and responsiveness. We still need to run more comprehensive tests, but I'm hopeful that we have the functionality we need now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewantonmate at yahoo.com Thu Aug 24 08:30:51 2017 From: thewantonmate at yahoo.com (Matt) Date: Thu, 24 Aug 2017 06:30:51 +0000 (UTC) Subject: [Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows? In-Reply-To: <2031848025.1170424.1503554379260@mail.yahoo.com> References: <1112359580.1778161.1503304197183.ref@mail.yahoo.com> <1112359580.1778161.1503304197183@mail.yahoo.com> <6D11BE60-C8E8-4088-BC49-F072152935A9@qt.io> <1217385248.2007493.1503329067030@mail.yahoo.com> <4A63C17D-E89E-4DF9-BC72-CBEF6927ADA2@qt.io> <1627822754.2502642.1503374534050@mail.yahoo.com> <1BFBE40C-877E-4BCD-ABE1-B55B10633334@qt.io> <1729977477.3051980.1503430069615@mail.yahoo.com> <4E475D55-3D15-4E62-849E-8C9153FB8555@qt.io> <1661714034.673218.1503503151580@mail.yahoo.com> <2031848025.1170424.1503554379260@mail.yahoo.com> Message-ID: <1143513193.1230184.1503556251867@mail.yahoo.com> P.S. As one would expect, while our application isn't sluggish, it does constantly consume 80-100% of the CPU even when WebGL content is not being shown, since it's using the software renderer for everything, not just QtWebEngine. An ANGLE related solution would really be ideal, as Chrome browser seems to work quite well across lots of hardware. But we realize that, sadly, there are technical reasons why this is currently not possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: