I want to ask: Can Emscripten and Electron be used together?

[Talha Enes Ayrancı]

Hi everybody.

Can someone explain to me this question? I browsed on web but I couldn't find descriptive things.
Maybe we can discuss this. Is this possible and why? If possible, what is the advantages or disadvantages?

Thanks for answers from now.

-Talha

[Shlomi Fish]

Hi Talha,

Seems like you can combine Electron and WebAsm:

* https://github.com/adamvoss/electron-webassembly-hello

Hope it helps, but note that Electron is very wasteful:

*
https://github.com/shlomif/shlomi-fish-homepage/blob/master/lib/notes/quality-software--followup-2018.md


--

Shlomi Fish https://www.shlomifish.org/
https://is.gd/htwEXQ - Integrating GNU Guile into GNU coreutils

*Reg*: All right, but apart from the sanitation, medicine, education, wine,
public order, irrigation, roads, the fresh water system, and public health,
what have the Romans ever done for us?
— Life of Brian (1979) ( https://www.imdb.com/title/tt0079470/quotes )

Please reply to list if it's a mailing list post - https://shlom.in/reply .

[Eric Mandel]

Hi Talha,

Our browser-based astronomical image display (https://js9.si.edu) is transformed into a full desktop app using Electron and a few hundred lines of wrapper code. Having the same code base for both environments is a huge benefit. We also very cautiously allow use of Electron's node capabilities to make the underlying file system available on the desktop app.The main drawback for us (compared to a pure desktop app using Aqua or X11) is lack of mmap() and the limit on the amount of available memory: our files are large (> 100Mb) or even huge (> 1Gb) and special techniques are required to cut down on memory use. 

We use Emscripten to compile cpu-intensive astronomical i/o, reprojection, and world coordinate system libraries to wasm. Although the results run at near-native speed thanks to Emscripten, our data processing takes much more time than an ordinary web app. As a result, we probably don't notice Electron-specific inefficiencies that others might.

Regards,

Eric

[J Decker]

On Mon, May 18, 2020 at 6:02 AM Eric Mandel <ema...@cfa.harvard.edu> wrote:

Hi Talha,

Our browser-based astronomical image display (https://js9.si.edu) is transformed into a full desktop app using Electron and a few hundred lines of wrapper code. Having the same code base for both environments is a huge benefit. We also very cautiously allow use of Electron's node capabilities to make the underlying file system available on the desktop app.The main drawback for us (compared to a pure desktop app using Aqua or X11) is lack of mmap() and the limit on the amount of available memory: our files are large (> 100Mb) or even huge (> 1Gb) and special techniques are required to cut down on memory use. 

re no mmap...

https://www.npmjs.com/package/sack.vfs  has a mapFile() function which isn't very complex itself, that just returns an ArrayBuffer...

https://github.com/d3x0r/sack.vfs/blob/master/src/vfs_module.cc#L921-L960   

Also, `--max-old-space-size=8192 ` should also work as an electron option to increase the JS heap size. (which apparently needs to be wrapped in an option https://github.com/electron/electron/issues/2056    --js-flags='--max-old-space-size=10192' )

We use Emscripten to compile cpu-intensive astronomical i/o, reprojection, and world coordinate system libraries to wasm. Although the results run at near-native speed thanks to Emscripten, our data processing takes much more time than an ordinary web app. As a result, we probably don't notice Electron-specific inefficiencies that others might.

Regards,

Eric

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/7017d53b-c824-4ea3-a5f8-1e6c941f48b6%40googlegroups.com.

[Sam Clegg]

On Mon, May 18, 2020 at 10:30 AM J Decker <d3c...@gmail.com> wrote:

On Mon, May 18, 2020 at 6:02 AM Eric Mandel <ema...@cfa.harvard.edu> wrote:

Hi Talha,

Our browser-based astronomical image display (https://js9.si.edu) is transformed into a full desktop app using Electron and a few hundred lines of wrapper code. Having the same code base for both environments is a huge benefit. We also very cautiously allow use of Electron's node capabilities to make the underlying file system available on the desktop app.The main drawback for us (compared to a pure desktop app using Aqua or X11) is lack of mmap() and the limit on the amount of available memory: our files are large (> 100Mb) or even huge (> 1Gb) and special techniques are required to cut down on memory use. 

re no mmap...

https://www.npmjs.com/package/sack.vfs  has a mapFile() function which isn't very complex itself, that just returns an ArrayBuffer...

https://github.com/d3x0r/sack.vfs/blob/master/src/vfs_module.cc#L921-L960   

Sadly even if node supports mmap, using methods such as this,  there is no way (today) to make that usable by a WebAssebmly module.

 

Also, `--max-old-space-size=8192 ` should also work as an electron option to increase the JS heap size. (which apparently needs to be wrapped in an option https://github.com/electron/electron/issues/2056    --js-flags='--max-old-space-size=10192' )

We use Emscripten to compile cpu-intensive astronomical i/o, reprojection, and world coordinate system libraries to wasm. Although the results run at near-native speed thanks to Emscripten, our data processing takes much more time than an ordinary web app. As a result, we probably don't notice Electron-specific inefficiencies that others might.

Regards,

Eric

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/7017d53b-c824-4ea3-a5f8-1e6c941f48b6%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAA2GJqU24CyweeeR7hpwzm5MsGNtijY9nsRJm4V2O8xDUDQ_uw%40mail.gmail.com.

[Eric Mandel]

If I recall correctly, our classic X11 desktop app mmaps the whole data file, gets the returned array buffer, and indexed into that array, allowing the *nix memory mapper to do the heavy work of reading in the correct pages. You have to be careful about access order to avoid excessive page faults, but otherwise we can rely on the operating system to make available the pages of our mega files. My understanding is that browsers (including Chrome used in Electron) don't support this sort of paged access. I'd love to be wrong about this ...