Scope & Limitations

Eido is a declarative, data-first Clojure library for generative art. You describe images as plain data — maps, vectors, keywords — and a native engine renders them.

It's an end-to-end toolkit for the full arc of a generative art practice — from REPL sketching to finished output. One library covers:

• Screen — raster PNG for stills and animated GIF for motion.
• Print — real-world units and paper-size presets, so you can author in centimeters or inches and render at print resolution.
• Editions — deterministic seed-driven series with parameter specs and trait analysis.
• 3D — mesh construction, cameras, and shading that resolve to 2D nodes for rendering.

The design commitments that keep the toolkit small:

• A library, not a framework. Every authoring function takes data and returns data. You bring your own workflow, editor, and REPL.
• No toolchain to install. The native rendering engine ships compiled inside the library — you need a JVM, nothing else.
• REPL-driven. The primary development loop is edit, evaluate, inspect, adjust.

Eido is an art tool. It was designed around the practice of generative artists — edition makers, creative coders — not around the needs of data visualization, dashboards, or scientific charting. Data-viz work is possible with the same primitives, but the API, gallery, defaults, and documentation all pull toward artmaking. If your primary goal is communicating data, reach for a dedicated charting library instead (see When to Use Something Else).

• CPU rendering. The engine rasterizes on the CPU — no GPU acceleration. This keeps rendering portable and deterministic, at the cost of being CPU-bound for very large or very complex scenes.
• Memory scales with scene complexity. Every node in a scene is an in-memory data structure. Scenes with 100k+ nodes use significant heap space.
• Sequential animation rendering. Each frame is rendered independently. A 300-frame animation takes roughly 300x the single-frame time; there is no delta-based rendering.
• Raster output. Eido renders to PNG and animated GIF. There is no built-in vector (SVG/DXF) or motion-control (G-code/HPGL) export.
• No streaming or progressive output. The full scene must fit in memory; there is no tiled or chunked rendering for very large canvases.

These are things Eido intentionally does not do. They represent different tools with different constraints — not missing features.

• No GUI editor. Eido is a library for programmers. Use your preferred editor and REPL.
• No CAD/CAM precision modeling. Eido's geometry is for visual output, not engineering tolerance. For precision modeling, use OpenSCAD or similar.
• No audio or livecoding. Eido is a visual system. For audio-visual work, pair it with Overtone or Sonic Pi.
• No web IDE or browser runtime. Eido runs on the JVM. ClojureScript is not a target.
• No photorealistic 3D. The scene3d pipeline produces flat-shaded and NPR (non-photorealistic) output. There is no ray tracing, PBR, or global illumination. For photorealism, use Blender or Mitsuba.
• No image compositing. Eido generates images from data. It does not import or layer external images (beyond palette extraction from reference photos).

Eido complements rather than replaces these tools:

• Interactive graphics — Processing, p5.js, nannou. When you need real-time interaction, mouse input, or immediate visual feedback beyond the REPL preview.
• Photorealistic rendering — Blender, Mitsuba, POV-Ray. When you need physically accurate light transport.
• Precision CAD — OpenSCAD, FreeCAD. When you need engineering tolerances and manufacturing output.
• Data visualization — Vega-Lite, Observable Plot, Oz. When your primary goal is communicating data rather than making art.
• GPU shaders — Shadertoy, ISF, Processing. When you need real-time fragment shader performance.