Replies: 2 comments 1 reply
-
Did you have to make any changes to support ANGLE or was it just alternate build commands? Are there any downsides to adding support? Right now it is tough to support multiple binaries for one platform, due to the way node-pre-gyp downloads a binary file based on a platform/arch/node-abi string . In the release workflows, it mostly builds the release with the default options. In testing, I have found it should be possible to supply node-pre-gyp a mirror where alternate binaries would be stored. |
Beta Was this translation helpful? Give feedback.
-
Hi, @etnav. I think ANGLE support would be bring as build option. Binaries other than the default build would be a separate project. Maybe when the project is split by platform, we could build releases for all variants (like EGL and OSMesa) we can bring this by default, but for now, I think it would be new packages, like @maplibre/maplibre-gl-native-egl, @maplibre/maplibre-gl-native-osmesa @maplibre/maplibre-gl-native-angle, etc. Or not hahaha. Just throwing ideas. |
Beta Was this translation helpful? Give feedback.
-
Hi,
would it be possible to have a separate windows release with ANGLE support?
Currently, when installing
Maplibre GL Native
via NPM (which is great btw), this installs the release without ANGLE support. My current workaround is to buildMaplibre GL Native
manually and then replace thembgl.node
with the newly builtmbgl.node
where ANGLE support is enabled. Quiet the overhead in my opinion.Interested to hear about why the default is to build without ANGLE support, since chromium (and it doesn't stop there) uses ANGLE.
@tdcosta100 Tagging you, since you did a great job with the windows build support and maybe you got an answer for me 😄
Beta Was this translation helpful? Give feedback.
All reactions