This is so that existing rendering libraries/binaries can re-use nannou/lyon heavy lifting and migrate to it in progression.
As an example, alacritty already has its rendering context, but the rendering of polygons and paths for decorations (i.e. background effects) could use nannou's logic.
While the vertices from certain shapes work without this PR (i.e. draw.ellipse()), when one attempts to use a draw.path(), this is behind several private layers: the Draw .state, the .intermediary_state and finally the .path_event_buffer where the vertices are located for bezier curves and such.
By exporting these immutable references of the state, other projects can start calling draw.<shape>()... and the project can have a function similar to nannou::draw::renderer::Renderer::fill() in which the draw commands are drained and primitives are rendered in the existing project rendering context.
This is so that existing rendering libraries/binaries can re-use nannou/lyon heavy lifting and migrate to it in progression.
As an example, alacritty already has its rendering context, but the rendering of polygons and paths for decorations (i.e. background effects) could use nannou's logic.
While the vertices from certain shapes work without this PR (i.e.
draw.ellipse()
), when one attempts to use adraw.path()
, this is behind several private layers: the Draw.state
, the.intermediary_state
and finally the.path_event_buffer
where the vertices are located for bezier curves and such.By exporting these immutable references of the state, other projects can start calling
draw.<shape>()...
and the project can have a function similar tonannou::draw::renderer::Renderer::fill()
in which the draw commands are drained and primitives are rendered in the existing project rendering context.Signed-off-by: Seb Ospina kraige@gmail.com