-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nbind updates coming #48
Comments
This looks really awesome! 🎆
According to you, this penalty could be noticeable in a GUI app like libui-node? Otherwise, it could be useful to use the precompiled binaries as default choice, doing compilation as a fallback. |
The speed difference really wouldn't be noticeable in a GUI app, probably less than a microsecond per call. Now that you mention it, I guess the precompiled binary might be the first choice in this case. |
Libui-node is now using last release of nbind, in branch 0_1_0. 🎉🎉 |
Installing
nbind
-based packages on Windows currently requires Visual Studio and Python, just like most other native binary Node.js addons. There's now a plan to change this.nbind
should eventually come bundled with a precompiled minimal binary addon for all Node.js versions, for communicating with a special entry point in shared libraries. It will then be possible to pass a flag tonode-gyp
and compile the project into a single.dll
,.so
or.dylib
with such an entry point, and put them in the npm package. In practice only the following should be required:.dll
for Windows.dll
for Windows.dylib
for OS XLinux users can probably get
node-gyp
working anyway.libui-node
would still be compiled and installed exactly as now, but if that fails, it could use a precompiled.dll
or.dylib
as a fallback. When in use, the fallback will introduce a tiny performance penalty for each call.I'm also investigating running the C++ code in another thread to avoid having to poll UI events, but that won't happen at least until next year.
The text was updated successfully, but these errors were encountered: