When using the HTMLViewer set to Webkit, results in +100MB extra files (Windows)
For me this is really a break point and something I really want to avoid.
Yes, I know, size is not ‘that’ important nowadays due to fast internet etc… still … I hate it (big times). So bare with me and read on:
I was playing with removing some chrome related files and folders making it still work.
What are the consequences when removing these files?
Here is a screenshot of the files that are created when compiling with Xojo.
Here are the files I could remove and having the HTMLViewer still working.
Removing the locales folder seems to be ok too.
Are there other files that I can remove?
If you use HTMLViewer and not DesktopHTMLViewer you get the option to not use CEF. Wouldn’t that solve your issue without risking breaking your program?
Well, the render used by xojo is ancient. It is a shame that xojo lacks the capacity to implement the current native render engine ( WebView2/Edge) and just ditched the native option. like 150 Mb just to display a simple html is ridiculous.
Those are involved in html graphics, mostly on web canvases (HTML5), check what happens when you try to run complex graphics as WebGL: https://webglsamples.org/
I completely dislike the idea of removing “parts” to see if it works, as you never know if doing so you introduce a new crash, or memory leak or something to be found only later.
Please check the WebView2 control from Microsoft. This control allows any Windows application to use the Chrome based Edge browser as a control within your application. Enjoy all the latest JavaScript, HTML and CSS features and replace use of Internet Explorer.
For MBS Xojo Plugins version 20.5 (or newer) we added a WebView2ControlMBS control, which you can drop on your window in a project. If run on Windows, the control will try to load WebView2 and put it in a control.
While I no longer work for Xojo, be very careful about removing things. If chromium depends on any of those dlls, it probably won’t check to see if they are there before using them. Same goes for the locales, make sure you test your app in the other locales. Missing things could easily cause crashes.
Some of those dlls are actionable if the current machine has a GPU able to handle it. If you are running in soft render mode you may not be affected by those vk*.* shaders, I wouldn’t risk removing d3*.* in any case. So, in some machines, some may not be affected, but others may. No sure if a crash or a fallback to soft mode is involved. I wouldn’t play dice for few bytes.
Maybe not? Because you don’t use a feature you never know if the engine use just ONE call there to get something about the environment. That one call could break things.
What you guys in search of peanuts want is an alternative CEF engine that could be used in place of the current one, a new compilation using a pure software renderer and removing those GPU acceleration dependencies enabling some safe dll removals.
Open a feature request for that. A smaller engine paying the penalty of being slower. I guess that can be done.
