Skip to content
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

Abstract a nannou_core crate for use in no_std or headless environments #752

Closed
mitchmindtree opened this issue Jun 15, 2021 · 0 comments · Fixed by #754
Closed

Abstract a nannou_core crate for use in no_std or headless environments #752

mitchmindtree opened this issue Jun 15, 2021 · 0 comments · Fixed by #754

Comments

@mitchmindtree
Copy link
Member

mitchmindtree commented Jun 15, 2021

@JoshuaBatty and I have often come across the desire to use nannou in headless or no_std environments, but without the deep stack of crates required for providing the event loop, wgpu context, etc. These include:

  • Using nannou to generate patterns for LASERs.
  • Using nannou in hot-loaded dynamic libraries.
  • Sharing nannou types with embedded devices that are a part of an art installation.
  • Using nannou types in rust-gpu code.

I'm thinking nannou_core could be home to those abstractions that don't directly interact with I/O, e.g.

  • The geom module (replacing our existing Point/Vector types with glam).
  • The noise module if possible... In theory it should be possible to include this, but we will have to investigate the feasibility of support for no_std. Support for #![no_std]? Razaekel/noise-rs#251.
  • The rand module with simple helper functions extending the rand crate.
  • The color module with palette re-exported along with our helpers.
  • The ease module (pennereq requires a #![no_std] feature, but should be a trivial contribution).
  • The text module with logic for laying out text. Would require #![no_std] support in rusttype which is currently unmaintained... we might have to address this anyway by switching to an alternative.

We could also add some more granular feature gates for these (e.g. serde, rand) along with a nannou_core-specific prelude.

Then, I imagine nannou would re-export the nannou_core modules resulting in an interface that is largely indistinguishable from the current one.

rust-gpu support

We might be able to also add a dedicated CI job that checks nannou_core against the spirv-unknown-unknown target to ensure we maintain compatibility with rust-gpu.

nannou_draw?

Possibly this might lead to a future where we can also separate out a nannou_draw crate that allows for using Draw to render directly to images or vectors in memory (i.e. svg, png, laser graphics, etc), without needing the whole winit+wgpu stack.

mitchmindtree added a commit to mitchmindtree/nannou that referenced this issue Jun 18, 2021
See nannou-org#752 for motivation behind adding a `nannou_core` crate.

Note that this commit does not yet replace the color, geom, math and
rand modules within the `nannou` crate. This will be performed in a
following commit.
mitchmindtree added a commit to mitchmindtree/nannou that referenced this issue Jun 18, 2021
See nannou-org#752 for motivation behind adding a `nannou_core` crate.

Note that this commit does not yet replace the color, geom, math and
rand modules within the `nannou` crate. This will be performed in a
following commit.
mitchmindtree added a commit to mitchmindtree/nannou that referenced this issue Jun 20, 2021
See nannou-org#752 for motivation behind adding a `nannou_core` crate.

Note that this commit does not yet replace the color, geom, math and
rand modules within the `nannou` crate. This will be performed in a
following commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant