Rust bindings

[WafflePersonThing]

Slowly working on some rust bindings. Opening this to ask some related questions and/or update on the progress.

[rossant]

Great, thanks! A couple of questions/comments:

1. Have you taken a look at Add first idea for rust api. #6 ?
2. I'm currently making improvements to the Cython bindings/Python API in the dev branch. You'll probably have to update your bindings when I merge the branch onto main. The principal idea is to follow more closely the C API and the hierarchy of objects, at the expense of user-friendliness. The philosophy in Datoviz is to provide a relatively low-level, loosely object-oriented API (App->GPU->context / canvas->scene->panel->visual, etc) and leave more convenient higher-level APIs to third-party bindings/libraries.

[WafflePersonThing]

Yeah, I took a look and it seems similar to what I'm going for atm. I'm trying to use the bindgen rust crate to automatically generate the bindings so that it could respond to any changes to the project and it seems like it may work. (also just a note I'm pretty new to basically everything(rust,c,git) so please feel free to give me any pointers)
edit: Is datoviz written around glfw, or would it be easy to let rust handle the windowing through a different api

[rossant]

Thanks for looking into it. I have no experience with Rust at all but I'm impressed by the language and community. I'm happy to help and support Rust developers interested in Datoviz.

Currently glfw is a hard requirement, but a longer-term goal would be to support other backends (Qt5 is the priority, there is some work in progress). I've made sure that the glfw-dependent code is isolated and somewhat abstracted away so that supporting other backends should not be too hard. I'd be interested in seeing an alternative windowing API to see how close it is from glfw and to see if I can update the code a bit to make the implementation easier.

[WafflePersonThing]

Keeps giving me this warning when I try to run a rust program with bindings to datoviz, not sure if its a big deal though since it doesn't currently stop it from running
validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_api_dump.json invalid layer manifest file version 1.2.0. May cause errors.validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_device_simulation.json invalid layer manifest file version 1.2.0. May cause errors.validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_gfxreconstruct.json invalid layer manifest file version 1.2.0. May cause errors.validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_khronos_synchronization2.json invalid layer manifest file version 1.2.0. May cause errors.validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_khronos_validation.json invalid layer manifest file version 1.2.0. May cause errors.validation layer: loaderAddLayerProperties: C:\VulkanSDK\1.2.176.1\Bin\VkLayer_screenshot.json invalid layer manifest file version 1.2.0. May cause errors.empty POS prop, skipping renormalization17:27:47.055 W C:\Users\tyler\CLionProjects\rust-bindings\src\vklite_utils.h:0276:

[rossant]

I think these are mostly harmless warnings, see https://www.gitmemory.com/issue/KhronosGroup/Vulkan-ValidationLayers/2729/824406355
I'll probably hide them from now on.

[WafflePersonThing]

Does the python bindings generator do some special handling with colormaps to get it to work? With bindgen and rust I cant seem to make bindings to the colormaps.h functions (bindgen cant generate bindings to inlined functions but it wont even generate bindings to the non-inlined ones in that file). Should they be exported or something so they can be used when datoviz is linked as a dll?

[rossant]

Have a look at: https://github.com/datoviz/datoviz/blob/main/bindings/cython/datoviz/pydatoviz.pyx#L557-L578

If that doesn't work with Rust, we could perhaps export a few colormap-related functions. Any suggestions for the functions and signatures?

[WafflePersonThing]

Also how does the branch structure of this project work? Should I make pull requests to the dev branch with the incomplete code and w.i.p's or wait till it's done and request to the main branch

[rossant]

I'd suggest to wait for a couple of days (hopefully) until I merge dev into main

[WafflePersonThing]

I'm not too sure which specific functions, it seems like all of the ones in the colormap functions section should be exported

[rossant]

Actually I don't expect most of these functions to be used directly. There are two functions that are vectorized (they work on arrays): dvz_colormap_array() and dvz_colormap_custom() and they should probably be exported. The other functions operate on scalar values and are typically used in loops, so they are inlined.

[rossant]

I'd suggest to wait for a couple of days (hopefully) until I merge dev into main

The dev branch has now been merged to main.