Hey All! Happy new year to everyone! In this week’s video, @bghgary gives us a fantastic first look at Babylon Native! Super exciting!
Will also the support to WASM or threads (Workers) be provided ?
However, I wonder why you prefered to go this route instead of using something like Electron (https://electronjs.org/) for eg?
Do you think you will get better performance by doing this way compared to hosting nodejs / chrome as they do in Electron?
Maybe the good surprise could come from the use of bgfx instead of WebGL (so Chromium-light, as they use in electronjs) …? no idea though
You ll get a smaller footprint and as there is no dom at all you save the entire cost of managing/rendering anything dom related
So in brief :
- No DOM, no WebGL layer and no chromium-light, but the rendering done with bgfx. Maybe it’s quite the same performance finally.
- same JS engine (V8 or other) than the browser’s one. Probably the same performance also.
Not sure the gain will really be in terms of performances.Probably rather in terms of versatility and portability : same initial code of a local application for any platform and, I hope, the access to APIs not currently available from the browser (ex : other protocols like smtp, ldap, to the file system, etc) or other node features (ex worker threads, if they allow better sharedArrayBuffers than the browser does)
Am I right ?
Memory will be a big difference and indeed versatility is a plus. CPU side the fact that there is no angle might help saving the extra checks required in a webpage so even if frame rate is pretty similar it should be for a much smaller required installed and memory footprint.
There might be an FPS gain, if your scene can sustain it, if implemented to run at the hardware refresh rate. I’ve heard some platforms of Occulus refresh @ 72 fps. Not that a browser on that hardware could not also do that as well, but there is probably going to be more overhead dragging a browser around with you.
Still no answer on the WASM question though. @jerome, I am thinking about rewriting / translating your VertexData.ComputeNormals() in Rust for my animation system & running via WASM. I have a couple of other bottlenecks as well, but could breaking that one out if someone want to implement it at the framework level.
I have not been very positive at efforts of WASM previously, since they were targeted at math routines. Not big enough to make it worth while.
Do not care about webworkers. WASM might allow threads in the future.
Electron will not let us run inside a native app (think about an objectiveC app)
Finally understand “portablity”, by .exe, and Drag-and-Drop JS-into-app is clever.
Small tears for PWA and FLEXBOX. Maybe not. Analog modules, is my guess.
Web Accessibility? Example subscription system API (servicebot).
Falcon wonders about VIDEO.
Native Video with Web Access. Seems the same through videoTexture.
Those are our considerations for early-adopting BJSNATIVE.
Any approximate roadmap for the first documented working release ?
Adding @bghgary for this one
We haven’t investigated deeply into this yet, but we certainly want it.
At this point, not yet. We are targeting support for glTF and standing up overall infrastructure first.
ok thank you for the answer