You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
@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:
rust-gpu
code.I'm thinking
nannou_core
could be home to those abstractions that don't directly interact with I/O, e.g.geom
module (replacing our existingPoint
/Vector
types withglam
).noise
module if possible... In theory it should be possible to include this, but we will have to investigate the feasibility of support forno_std
. Support for#![no_std]
? Razaekel/noise-rs#251.rand
module with simple helper functions extending therand
crate.color
module withpalette
re-exported along with our helpers.ease
module (pennereq
requires a#![no_std]
feature, but should be a trivial contribution).text
module with logic for laying out text. Would require#![no_std]
support inrusttype
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 anannou_core
-specific prelude.Then, I imagine
nannou
would re-export thenannou_core
modules resulting in an interface that is largely indistinguishable from the current one.rust-gpu
supportWe might be able to also add a dedicated CI job that checks
nannou_core
against thespirv-unknown-unknown
target to ensure we maintain compatibility withrust-gpu
.nannou_draw
?Possibly this might lead to a future where we can also separate out a
nannou_draw
crate that allows for usingDraw
to render directly to images or vectors in memory (i.e. svg, png, laser graphics, etc), without needing the whole winit+wgpu stack.The text was updated successfully, but these errors were encountered: