Hello,
I have just converted a Windows app to make it framework 2 compliant.
Before its compiled dimensions was around to 50 MB, now is 260 MB !!! 
How is possible?
If you are using a DesktopHTMLViewer on Windows it now always includes the Chromium Embedded Framework. If you are using a HTMLViewer setting the Renderer to WebKit will do this as well (not that this information is available in the new documentation).
I really donât like this. The DesktopHTMLViewer should definitely have a way to choose which renderer to use. 210MB extra is about a crazy as it gets.
As the Circle of Topics⢠goes, Anthony talked about this previously and Iâm in agreement with his point of view.
1 Like
The components are the same, converted to Desktop with the needed code adaptation. This has caused the compiled structure to entirely changed.
Now there is a large âLocalesâ folder with a lot of unuseful languages that there wasânt before. Also a lot of new DLLâs I never seen before.
I am impressed (and also a little angry)! My setup package size is increased of 150%
Iâm not sure if you can strip Locales on Windows the way you can on Mac, but maybe thatâs worth a try?
As far as the new DLLs, the 64-bit DLLs are not optional. The âInclude Runtime DLLsâ option is.
Iâm not sure what else to suggest. Even with two entire builds (a desktop and a console helper), my most complicated app Lifeboat is only 105mb on Windows. I use localized stings/constants and donât have a Locales folder. Perhaps @anon20074439 or @William_Yu knows why.
A bystanderâs question: by todayâs amount of RAM and disk space, is it really a concern?
Not in absolute terms. Maybe I worry about nothing becouse I just I donât know the reasons for this abnormal increase. Maybe someone will be able to explainâŚ
I donât see whether you answered the question about whether you are using HTMLViewer or DesktopHTMLViewer in your project, but that would explain a lot of this. Chromium (the underlying technology) has a lot of stuff built in so things will just work. Because itâs all encapsulated, the Xojo compiler does not do any code stripping for it.
List your previous Libs folder (files and sizes) and the current one. Letâs compare to understand. Also inform what was the old Xojo version and the current one.
The âlocalesâ folder mens you are using Webkit, in Api2, is the DesktopHTMLViewer, where Xojo decided to remove support for the native renderer that uses the one installed in the PC instead of shipping those 100+ extra Mb.
You already received the answer, if you dont like this increase, just dont use the Api2 DesktopHTMLViewer, go back to the Api1 Htmlviewer with the native renderer.
He said; âThere was already functionality that couldnât really be ported reliably to the native renderer âŚâ
The current native renderer in windows is the edge WebView2 runtime, which already uses a chromium base⌠So, what chromium functionality couldnât be ported to have consistency with chromium? 
Edge WebView2 runtime is installed on most pcs either by being there in later versions or by the massive rollouts. to cover the tiny percentage of pcs without it, a 2mb installer can be shipped with the app installer.
The current Native renderer in Xojo Desktop API 1.0 is not the Chromium-based WebView2 library, but the old IE runtime, which requires additional work just to get support for modern rendering and JavaScript execution, not to mention communication between the renderer process and our own Xojo code.
If the currently implemented âNativeâ renderer were actually WebView2, there might be an argument here. As it stands, CEF on Windows provides the best compatibility, capability and support of the options Xojo supplied out of the box. WebView2 support may be in the cards for a future Xojo release, but that wasnât added at the time of the Desktop API 2.0 switch and isnât available to us now. In my eyes, Xojo made the choice to remove a subpar option, which I agree with.
1 Like
Yes, xojo didnt implement the current technology, but for the deprecated one, it will be available for many years as backward compatibility.
Considering that many, many use cases of this control is to display simple HTML rendered ok on the las IE⌠In my eyes, Xojo take the bad choice, remove a working feature and force the user to increase its app size by 100+ mb instead of just documenting the limitations of the native renderer. It should be up to the user to decide what to use depending on the intended use, IE for this, the bullky cef for that.
1 Like
Thanks you all for help me to focus the issue.
Excluding a small and forgotten Htmlviewer the global size of the project is now reduced at 1/5.
I was using it to read few line of text from a webpage, but I think I can find a lighter alternative for this task.
No if your internet spedd is light speed.
But for the most part of Planet Earth Internet users, it is not the case⌠so, concern there is.
So you consider an app with only a HTMLViewer ends up being 270MB size is acceptable? Hmmm⌠
1 Like