Scope & Limitations

Eido is a declarative, data-first Clojure library for generative art. You describe images as plain data — maps, vectors, keywords — and Eido renders them to the medium you're working in.

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, animated GIF, and animated SVG for digital editions and screens.
• Print — real-world units, paper presets, DPI control, and archival TIFF for giclée and fine-art printing.
• Fabrication — stroke-only SVG with pen layers, deduplication, and travel optimization for pen plotters, and polyline export for CNC mills and laser cutters.
• Editions — deterministic seed-driven series with parameter specs, trait manifests, and contact sheets.

The design commitments that keep the toolkit small:

• A library, not a framework. Every function takes data and returns data. You bring your own workflow, editor, and REPL.
• Zero production dependencies. Just Clojure and the standard library. Nothing to install, nothing to break.
• REPL-driven. The primary development loop is edit → evaluate → inspect → adjust. No compile step, no build tool.

Eido is an art tool. It was designed around the practice of generative artists — plotter 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).

• Software rendering only. Eido uses Java2D — no GPU acceleration. This is deliberate: it keeps the library portable and zero-dep, but it means rendering is CPU-bound.
• Memory scales with scene complexity. Every node in a scene is an in-memory data structure. Scenes with 100k+ nodes will use significant heap space. Large batch renders benefit from the :perf alias JVM flags.
• Sequential animation rendering. Each frame is rendered independently. A 300-frame animation at high resolution takes 300× the single-frame time. There is no incremental or delta-based rendering.
• Single-threaded rendering. The render pipeline processes one scene at a time. Parallelism is available at the batch level (e.g., rendering editions with pmap), but a single render call is single-threaded.
• 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. A visual seed browser is a separate project idea (see IDEAS.md).
• 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 beyond polyline export.
• 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.