The first public Beta release of our latest HTML Executable version 2023 is now available. The most significant update in this release is the incorporation of Microsoft WebView2 as another HTML rendering engine, promising to deliver unparalleled performance and a smaller size for your ebooks compared to the stand-alone CEF engine.
Please keep in mind that this is a Beta release. We are still refining and finalizing the software, particularly given the extensive changes brought about by WebView2. While the documentation is being updated, there may still be bugs present. We encourage you to use this Beta version with caution, make regular backups of your projects and source files, and please report any issues you encounter to G.D.G. Software. We appreciate your understanding and assistance.
Warning: if you have a previous version of HTML Executable (2022, 2021 or 4.x), it will be upgraded to version 2023.
HTML Executable 2023 can import projects made with previous versions, including 4.x and 2022. However, some issues may occur due to the extensive internal changes in this release: please refer to the Readme for guidance.
The licensing system is operational. Therefore, if you are a customer with an active maintenance, you can activate this Beta and produce EXE files with no limitations. For those whose maintenance ended after the last update, we’ve automatically extended it at no cost to you. If you’re not covered by maintenance, HTML Executable 2023 will operate in the trial state as explained in the Store page.
HTML Executable 2023 is a major release that significantly enhances the software’s capabilities in all areas. We’ve chosen to keep this version in beta a bit longer due to the significant internal changes brought about by the introduction of WebView2. We’re committed to delivering a flawless product and want to iron out any potential issues before releasing the final version later this year.
I’ve checked a WebView2 option and it’s perfect, but I got a new issue: WebView2 renders pages as is, but I need a web-server emulation like we had for IE or CEF. My project needs this web server emulation to work…
Using a test publication with a component that depends on loading three.min.js (639kb; included internally as a file), this one component screen takes about 20 seconds to navigate to from my menu button click and load. Once loaded, works flawlessly (the animation generated is at perfect speed). But, I wonder if there is a way to set up preloading of this or another js library? This would help so that when this component, that depends on three.min.js, is navigated to, the three.min.js is already (pre)loaded and available. May cut down on waiting time. BTW, for the three.min.js file, I tried no compression, streaming compression. Didn’t speed the component’s loading time.
Only workaround I can think of would be to add a loading spinner to my menu screen so the user waits the 20 seconds until the component screen displays. Not sure what else would work?
Sorry, I don’t understand what you mean by “Web-server emulation like we had for IE or CEF”?
And CEF is still available in HTML Executable 2023 and updated to the last version that handles Windows 7.
Is it with webview2 or CEF?
And does your app loads other assets? Because even it’s 639kb, it’s rather small. Or you can try to enable the Media Compatible compression method in File Properties for that file?
Like it was working http://127.0.0.1/… and not like file:///. Another issue is that I can select some contents and copy it with Ctrl+C. Also, search engine can find some data from pages disabled for demo version.
Publication .EXE has been compressed with success.
Packaging publication data up and merging…
o Bundling CEF Runtime
Compression Error: Not enough memory resources are available to complete this operation
FATAL ERROR
The following error has occurred during compilation:
Cancelled
While three.min.js is a small file, did some reading about three.js and there are reports of slow loading problems. However, the HTML5 project (published as HTM) that is being used for creating the EXE, when run via the HTM, three.min.js loads and runs with no noticeable delay.
When creating the EXE, everything else loads and runs OK. Only the three.min.js loads slowly (about 20 seconds). Once loaded it also works OK.
(1) CEF
(2) If by Media Compatible compression, you mean checking the compression box in three.min.js properties>advanced, I tried this. The result was a crash (sent GDG bug report) while compiling (screenshot of property setting attached)
. Is there another location for Media Compatible compression?
(3) Separate issue: In doing more testing, noticing some hanging while compiling CEF projects. Use Task Manager to end program, then try again. Sometimes compiling works, sometimes not. Cannot associate anything specific to the crashes.
UPDATE (06/11/23)
My project’s component that depends on loading three.min.js is one of several components/screens in the full, larger (multi-component/screen) project. I created a new, smaller project with only the three.min.js-dependent component (single screen project), used the BETA and CEF to compile, and it loaded quickly (no delay) and ran perfectly. So, the slow-loading issue is not likely caused by three.min.js but rather by the size of the full project or even by the location of the three.min.js-dependent component (in the project tree sequence), which may cause a loading problem for the three.min.js file in the CEF compile? Hope this can somehow be fixed in the BETA/final public release since I need to compile (to EXE) larger projects with multi-components/screens like this project.
So, If I apply this setting to the three.min.js, loading of the page that depends on this library improves by a few seconds: instead of ~20 seconds loading time, down to ~15-18 seconds.
Also, sometimes still endlessly hanging when compiling: so far cannot isolate what causes this intermittent hanging while compiling. Task manager needed to exit out of HTML EXE. Try again, sometimes after enabling/disabling compression, and then works OK. Puzzling. Will keep testing, see if I can isolate any potential cause.
Further testing, now using WebView2, same large project: no loading delay for three.min.js or any other project file. So far, WebView2 works flawlessly.
Still getting compilation hanging when standard compression is not disabled or media compression is enabled. Does not happen when “Do not compress selected files…” is enabled. So possibly compression issue?
Strange bug. Since compression is multi-threaded, maybe that could be the reason. You can try in the environment options of HTML Executable to disable multi-core:
Tried disabling multi-core compression and CEF multi-core compression as suggested, setting the engine to CEF. Took 15-22 seconds to load the screen that depends on three.min.js.
As mentioned above, WebView2, works well, with no loading delay.
Warning: if you have a previous version of HTML Executable (2022, 2021 or 4.x), it will be upgraded to version 2023.
