Tracking Issue: Tables and attributes for graphical data

[Keavon]

This involves moving towards a unified conceptual model for procedural graphical data based around tables (a data type represented by a spreadsheet) and attributes (the columns of a table).

New instances-based concept design notes (as we designed during the Maker Faire)

Here are the notes Adam took while he, True Doctor, and Keavon discussed the design while driving to the Maker Faire:

All data is

struct Instances<T> {
    // Datastore: HashSet<Reference, T> (this is an older idea, before choosing to use Rc<Mutex<T>>)
    instances: Vec<(String, Vec<TaggedValue)>>
    // First column is Rc<Mutex<T>> second column is transform, footprint, click targets, vector modify,
    // overlays, other columns that the user adds. This forms the spreadsheet.

Vector data transforms stored in Vec<(NodeId, Transform)>, each monitor node adds an entry, the transform node multiples the rightmost.

No appearance data, color/thickness/properties used by renderer are stored in table.

Rectangle node creates Instances<VectorData>, which can be added to a group of Instances<GraphicElementInstances> when it enters a layer stack

enum GraphicElement {
    Vector(Instances<VectorData>),
    ImageFrame(Instances<ImageFrame>)
    // Etc.
}

Old pre-instances concept design notes (prior to the Maker Faire)

Design for the new table-based graphical data structure

Using this syntax:

Definition	Description
Struct = { Field1, Field2, ... }	Rust struct
[Table] = [Attribute1[], Attribute2[], ...]	Either a HashMap, or Rust struct, of parallel Vecs shown as a spreadsheet
Union = Type1 | Type2 | ...	Rust enum of 1-tuple type variants each named after its type

Elements, which all implement trait Graphical (renamed from the currently named GraphicElementRendered):

• [Element] = [ElementId[], (dyn Graphical)[], Transform[], AlphaBlending[]]
• VectorData = { [Point], [Segment], [Region], ColinearManipulators, FillRule, SvgFilter, FutureMeshVectorInfo }
• Raster = // to be designed
• SDF = // to be designed
• Color = // to be designed
• Gradient = // to be designed

VectorData tables:

• [Point] = [PointId[], Position[]]
• [Segment] = [SegmentId[], Start[], End[], Curvature[]]
• [Region] = [RegionId[], SegmentRange[], PathStyle[]]

([Element] is formerly GraphicGroup; FutureMeshVectorInfo is additional data for the format we'll design in the future for vector meshes; we need to guarantee no collisions with each table's ID which acts as the database key)

And these are some additional details about the vector, raster, and SDF data in both their raw and resolution-aware forms:

Greater purity/usefulness
│
│   ┌───┬────────── Node signature: () -> VectorData         (SVG or Pen tool shape or Rectangle node output)
│   │   ├────────── Node signature: Footprint -> VectorData  (Tile generator or infinite repeat node)
│   └─> │   ┌────── Node signature: () -> SDF                (SDF generator node output, to be implemented)
│       ├─> ├────── Node signature: Footprint -> SDF         (Cullable procedural SDF generator node output, to be implemented)
│       │   │   ┌── Node signature: () -> Raster             (ImageFrame, a bitmap with a location, exists today)
│       └─> └─> └─> Node signature: Footprint -> Raster      (Resolution aware raster, to be implemented)
V
Lesser purity/usefulness

• () -> Data means "I will give you all the Data, which obviously must be finite".
• Footprint -> Data means "I will generate a view into the Data for some rectangle in space, because it might not even be finite".