As a fan of “just works”, without peeking the system and trying to fix it to my needs playing with the registry, MAYBE breaking something else that the user depends on with the settings that are there, and after some headaches with systems of my users with their “native” engines broken, I decided always to add that ridiculous small 100MB CEF engine that allows me to use executeInXojo() and executeInXojoSync() that I need and no regrets so far.
So, FOR ME, using “native” is a burden, not a solution.
To be honest, I am not sure if I really need to enable WebKit, but Google pointed me to some answers where this was mentioned. I just tried to play around with it to figure out, if it helps with my actual problem.
Confirmed: HTMLViewer works as epected, but DesktopHTMLViewer seems to only support WebKit/CEF.
The overhead for the WebKit renderer is about 200MB, actually. A simple “hello world” app is 40MB with the native renderer, but over 240MB with Webkit. [Testing in a 64 bit app. 32 bits may be “only” 100MB]
For now, I am superimposing the MBS control on top of a legacy HTMLViewer (using Native.) Which one to load, and render visible, is decided after testing for WebView2 availability (also done within the plugin.) This nicely saves the WebKit overhead in the built app, which in itself was roughly twice the size of the rest of the code combined.
Hi there, I not so sure about this statement, when I upgraded to API2 and obviously webkit as the renderer for my HTML viewer my compiled app actually shrunk from 26mg down to 18meg, I was using the native renderer before. No one has really be able to explain the massive decrease in compiled application size after the change, so I’m not sure that webkit is the culprit…
I am referring to build size on Windows. If you use WebKit, Xojo will bundle more than 100MB worth of Chromium stuff into your app. WebKit is built-in on Mac (and on Linux, though it may be optional on some distros.)
I could have been more specific, but I thought it implicit because the “WebKit/Native” issue is always in the context of Windows. The WebView2 (with MBS) option I mentioned is also strictly a Windows thing.
These look like Mac screenshots. In this respect you didn’t change anything when you switched from “Native” to “WebKit”. The old HTMLViewer always used WebKit on Mac and Linux, with the “Native” setting being irrelevant. On these platforms, WebKit “is” native.
The build-size difference, that you mentioned, is interesting. I’m only guessing but it might be that the new DesktopHTMLViewer has less overhead, with no Windows “Native rendering” support that might still compile as cruft into other targets. Be assured, though, that on Windows your app will be a monster. Heck, I’d have to look to see if I could get a Windows “Hello World” into your size.