[Qtwebengine] QtWebEngine + WebGL + ANGLE + Intel + Windows?

Matt thewantonmate at yahoo.com
Tue Aug 22 21:27:49 CEST 2017


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 <alexandru.croitor at qt.io> 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 <alexandru.croitor at qt.io> 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 <qtwebengine at qt-project.org> 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 <alexandru.croitor at qt.io> wrote:



On 21. Aug 2017, at 17:24, Matt via QtWebEngine <qtwebengine at qt-project.org> 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: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20170822/93dac153/attachment.html>


More information about the QtWebEngine mailing list