This crashes somewhat reproducibly on Firefox 66.0.3 (64-bit) while rotating the view around with the middle button:

RuntimeError: integer overflow solvespace.wasm:714979:1
    __ZN10SolveSpace14GraphicsWindow5PaintEv https://files.whitequark.org/SolveSpace/solvespace.wasm:714979
    __ZNSt3__228__invoke_void_return_wrapperIvE6__callIJRNS_6__bindIMN10SolveSpace14GraphicsWindowEFvvEJPS5_EEEEEEvDpOT_ https://files.whitequark.org/SolveSpace/solvespace.wasm:1609025
    __ZNSt3__210__function6__funcINS_6__bindIMN10SolveSpace14GraphicsWindowEFvvEJPS4_EEENS_9allocatorIS8_EEFvvEEclEv https://files.whitequark.org/SolveSpace/solvespace.wasm:1608486
    __ZNKSt3__28functionIFvvEEclEv https://files.whitequark.org/SolveSpace/solvespace.wasm:523996
    __ZN10SolveSpace8Platform14WindowImplHtml14RenderCallbackEPv https://files.whitequark.org/SolveSpace/solvespace.wasm:584709
    dynCall_vi https://files.whitequark.org/SolveSpace/solvespace.wasm:6951237
    dynCall_vi https://files.whitequark.org/SolveSpace/solvespace.js:10826
    dynCall https://files.whitequark.org/SolveSpace/solvespace.js:548
    dynCall_wrapper https://files.whitequark.org/SolveSpace/solvespace.js:527
    wrapper https://files.whitequark.org/SolveSpace/solvespace.js:7209
    safeRequestAnimationFrame https://files.whitequark.org/SolveSpace/solvespace.js:6740

@q3k Yes, this is a known issue in wasm. I'd need to look at a way to make overflowing float to integer conversions defined without losing performance or compatibility.

I've updated the branch to use upstream (i.e. LLVM's) wasm support in emscripten. This results in a very nice 5.5 MB deployable binary when built with -O3.

Just want to tell you that this is super awesome!! Love seeing things like this being ported to the web =)
Would it be possible to have the solver compiled separately so it can be used in other applications?

The solver is already buildable separately. I think you can just use current code from master with possibly minor modifications if you want to use it in your own WASM application.

How is this going. I played with the demo but it seems to have a offset on the mouse pointer location.

@mmiscool I haven't spent much time on this PR as other SolveSpace issues seemed more important. Which browser are you using?

In general, this PR probably won't be usable with real world designs until something is done with savefiles, which is a rather large task; right now there is no way to load an assembly in the web version even in principle.

@mmiscool I haven't spent much time on this PR as other SolveSpace issues seemed more important. Which browser are you using?

@whitequark I am using google chrome.
See the following video for behavior.

https://youtu.be/15hT13KPBMs

In general, this PR probably won't be usable with real world designs until something is done with savefiles, which is a rather large task; right now there is no way to load an assembly in the web version even in principle.

For file management have you looked at using local storage? The solvespace file format is just text at the moment, I could put together some javascript to handle file management.

For file management have you looked at using local storage? The solvespace file format is just text at the moment, I could put together some javascript to handle file management.

I'm well aware of local storage. I don't consider a solution that is limited to 5 MB of total model size (which is easily exceeded as SolveSpace serializes triangle mesh to text with high decimal precision) and requires manual synchronization between browser and desktop acceptable.

See the following video for behavior.

That's a known issue. IIRC Chrome flat out broke the devicePixelRatio API several months back, at some point after I did the port.

right now there is no way to load an assembly in the web version even in principle.

Assembly files can be opened one-by-one through openfile dialog. Hard, but then we can save all the assemby into one metafile (zipped folders for ex).

Assembly files can be opened one-by-one through openfile dialog.

Again, I don't consider that solution acceptable.

but then we can save all the assemby into one metafile (zipped folders for ex).

This has been the plan for the new file format for a long time, and once this is implemented, then emscripten port can actually be released.

I would be interested in abstracting the file storage with a bit of javascript. I have another project that uses a database for managing storage of parts from a multi cad environment.

If file storage was done with an array of objects that could be accessed with the addition of some javascript it would be great.

Is that for Autodrop3d? I understand that it would be convenient for your project, but I don't think it's the right choice for upstream SolveSpace.

That said, I think you'll find it fairly easy to implement file operations in a similar way to other JavaScript implementations of platform APIs, and if not, I will gladly assist you with that.

@whitequark
I will work on getting some javascript put together for talking to my back end and try to ensure that it is generic so that others can use it a a basis for other similar server integrations. Will probably need your help working out how to do the talking with the web assembly module.

Cool! I'll see how much of that could be integrated.

I've rebased the branch on master and fixed a few minor issues.

If anyone's interested in this Emscripten port, I've rebased this commit against current master and fixed a few errors caused by emscripten breaking changes, such as the DOM library now using querySelector instead of getElementById. It builds and runs fine using Arch packages as of today.

@whitequark I think you will be glad to hear that after @verylowfreq picked up the Web emscripten port in #1275, it is now merged in trunk here 7415048a5769c78fc4bb02afa426d101059374d .

He also has saving and opening of files and gestures (for touch screens/phones/tablets) working here:
https://github.com/verylowfreq/solvespace/commits/feature-em-fileio
https://github.com/verylowfreq/solvespace/tree/emscripten-develop
And a live version with these changes here:
https://verylowfreq.github.io/experimental-solvespace-on-browser/

It still remains very experimental, but is usable for single file projects.

With this I am closing this pull request. Thank you for all the great work - I can not say this enough times :-)

More improvements in #1308 and #1310
Current status of:

Known issues from @whitequark

The major missing features are:

• Tooltips are not implemented.
• Preferences are not saved.
• Any way to open or save files. This is particularly bad because of the way SolveSpace handles assemblies. It is likely that New file format #75 will be required before this port is usable in any meaningful way.
• Some message dialogs (the ones that require a choice, specifically) are written in a blocking style and need to be may be rewritten with callbacks. It is also possible to use "new Asyncify" as of 2020, and might be preferable to do so.
• There's no way to move the "split" between main window and property browser.
• Scrollbars are not implemented, so there's no way to scroll the property browser.

The following are known bugs:

• Menu mnemonics are broken, the Alt+... hotkeys don't trigger them. No idea why.
• Pressing Esc does not dismiss message dialogs.
• Pressing Esc while editing a property also invokes the Esc keybinding, changing the open page in the property browser.
• Fullscreen is broken. The browser hard-stretches the entire canvas over the entire screen, ignoring element sizing. This is apparently required by the spec?

Additionally, there are some Firefox-specific issues:

• Fractional devicePixelRatio factors don't work (result in broken rendering). ( @ruevs See Platform: Fix GUI scaling on devices with non-integer pixel ratio #1310)
• Something about the styling and/or <canvas> doesn't work the same, and the canvas is stretched vertically under the menu. ( @ruevs: I do not understand or it is fixed)
• Shift-RMB cannot be used to rotate the sketch as that is hardcoded to bring up the browser menu, as a security feature. (It still rotates but the menu is in the way and input handling code can get confused.) (ruevs: On Firefox 106.0.5 it works fine, the browser menu pops up only after the drag is finished)

Known issues from @verylowfreq

• When exporing OBJ triangle mesh file, .obj and .mtl file are generated. But you can download only the obj file (download dialog for the mtl will not be shown.)
• UI is implemented both of C++ and Javascript.
• UI that implemented in Javascript doesn't refer translated texts provided by gettext.
• UI for uploading/downloading file is not good and not stable.
• Downloaded filename includes fullpath in psuedo filesystem that not useful for endusers.
• File can download only when save dialog closed.
• Zoom in/out with mouse wheel is not optimized. Too big step on some device.
• Exporint Triangle Mesh is often not working.
• Too much memory requests (> 2GB) and crash or the tab will freeze.