OK, here is what has been done on each W10 PC with an nVidia graphics card that Xojo-CEF can’t accelerate:
Run Windows Update (all were already up to date).
Download the most recent nVidia driver (STUDIO) and install it.
Reboot the computer.
It did NOT change anything. The device manager correctly states that the driver publisher is NVIDIA and that the driver release date is from 2 weeks ago. It’s brand new.
Download the most recent nVidia driver (GAME READY) and install it.
Reboot the computer.
It did NOT change anything either.
At this point, I’m ready to throw the towel. Xojo-CEF is currently incompatible with nVidia GTX 10 series (and probably other high end series too). What a shame, especially considering that the native browser on all those PC’s properly accelerates WebGL without any issue.
To summarize where we are with the issue (WebGL not hardware accelerated under some Windows 10 / Xojo combinations):
I could reproduce the issue using Xojo 2019 (HTMLViewer) but not Xojo 2022R1.1 (HTMLViewer). To me this strongly suggests it is CEF related.
@Ben_D sees the problem with Xojo 2021 and 2022 - this suggests there is a second variable (NVIDIA vs. Intel vs. AMD drivers?)
Nobody has yet filed a feedback case about this, and (assuming this is a Xojo/CEF issue) is not likely to get fixed until then.
Workarounds:
Use HTMLViewer in native mode (with proper settings of FEATURE_BROWSER_EMULATION and FEATURE_GPU_RENDERING) . Pros: IE11 keeps getting updates and runs WebGL pretty well. App size will be small since it’s not includeing the 100MB+ CEF libraries. Cons: IE11 does not support some modern javascript/html/css features, so your existing code may not work
Another con about using the IE11 based HTMLViewer control is that I could not get it to work under W7 at least not for WebGL web apps. I understand there may be tweaks in the Windows registry and hacks that you can do to force it to work, but it’s not worth it to me. I can’t possibly imagine giving my app to friends and telling them to hack their registry to make it work. The WebKit HTMLViewer is working exceptionally well as a turn key solution under W7 (and probably W10 too, unless you have an nVidia GTX 10 series card it seems).
I am now reading on other forums that many people complain about CEF/Chrome compatibility with nVidia graphics cards. Some people suggest that Chromium rolled back something last year that blocked some of the nVidia chipsets. They also suggest that you can UNBLOCK some of them by accessing this URL: chrome://flags and I am now investigating this a little bit further, I’m only beginning to read on the topic.
This makes me wonder: Is there a way in Xojo (or by altering the built files?) to edit the CEF launch command line? I could try add the –ignore-gpu-blocklist parameter perhaps?
I have extensive experience with this (I sell a commercial product which uses WebGL under Windows 7 running in a Xojo HTMLViewer). The only requirements:
your app must set the 2 registry keys
Windows 7 must be reasonably up-to-date (so the version of IE11 installed is patch level 11.0.110 or higher - which was current a few years ago).
That’s it - nothing very fancy is required.
I’m happy to help if you want to go this direction (but we should probably start a new thread?)
I will keep the door open as a last resort, but yes, we shall move to another topic if we proceed with this. At the moment, it’s out of the question until I can make sure that my WebGL app runs under W10 in that native HTMLViewer control (which I believe won’t be IE11 under W10 but probably WebView2, correct or is IE11 STILL a thing under W10 in 2022?)
EDIT: Welp, I just tried your suggestion to compile with a native HTMLViewer control instead of the DesktopHTMLViewer (and/or the WebKit HTMLViewer which I had at the beginning of this topic) and nope, it doesn’t run under W10. So it looks like it’s even worse with the native HTMLViewer, because now it doesn’t run under any OS at all. At least with WebKit it runs everywhere, just it’s not accelerated with nVidia chipsets, but it is with other chipsets AND it works flawlessly under W7 without any registry hacks too. When I open the HTMLViewer window it immediately crashes with this error:
FYI, my HTMLViewer makes extensive use of both ExecuteJavaScript and ExecuteJavaScriptSync, which might be why it’s crashing with the native HTMLViewer control… but if it’s the case, then I don’t understand why Xojo would even compile without warnings.
Actually, the IE11 renderer for Win32 apps is probably going to be supported for a billion years, since there are so many apps that depend on it.
Yeah, that’s probably it.
Do you have standalone HTML/Javascript/CSS/WebGL you can test with? A quick & dirty test is to open up IE11 and try to run it there - if it works in the IE11 app, it will almost always work under Xojo / HTMLViewer / Native (IE11) when configured properly.
I confirm this is crashing on ExecuteJavaScriptSync(). So, what good will that do if I can’t control anything in my web app? If all I wanted was to pop up a browser tab, I’d pop up a browser tab?
BTW, isn’t that funny that they deprecated the HTMLViewer control in favor of DesktopHTMLViewer last year in 2021r3.1 but yet, in 2022r1.1 a year later, the library window still only lists HTMLViewer
The super is what is different.
The HTML Viewer control (from the Library) is now by default a DesktopHTMLViewer. You can change it to HTMLViewer by changing the super without the need to drag/add a different control from the Library.
Ironically, it’s not, at least not in 2022r1.1 here. When I look up “html” all I get is HTMLViewer and when I drag this onto a window, it creates a HTMLViewer, not a DesktopHTMLViewer
OK but if HTMLViewer has been deprecated for almost a year, why does Xojo 2022r1.1 still defaults to super HTMLViewer instead of super DesktopHTMLViewer?
My Xojo license can ONLY create Desktop applications so that’s what this is. I created this project when I purchased Xojo 2021r3.1 approx. 2 months ago and there was already a notice in the documentation that it was deprecated starting from my release. Since then, I have installed Xojo 2022r1.1 and this project has been opened and saved in Xojo 2022r1.1.
I was not aware of this and my window is of type Window. Does that make any difference when you compile since I can only compile to desktop applications anyway or should I change all my windows to type DesktopWindow?
In any case, all the HTMLViewer controls that I use right now were set (manually, by me) to super DesktopHTMLViewer and that seems to make no difference with the problem at hand discussed throughout this topic (nVidia incompatibility with HTMLViewer and/or DesktopHTMLViewer).
BUT I asked a question yesterday that was left unanswered and I think now is a good time to re-ask: When you change the HTMLViewer control to super DesktopHTMLViewer, the behavior drop down disappears so I can no longer select between NATIVE and WEBKIT. Does DesktopHTMLViewer intrinsically compile to use WEBKIT or something else?
If your Window is DesktopWindow the controls you drag from the library will be DestopXYZ.
If your Window is Window the controls you drag from the library will be XYZ.
If you create a brand new project with Xojo 2022, your app will default to DesktopXYZ (App, Window and Controls).
You can change the super for your App, Window and Controls if you want or need (future fixes just in Desktop controls).
I think there are some differences with the events, you will need to evaluate what you want to do. If you are just starting out maybe is better to go full DesktopXYZ.
