Overview
Two Syndicate actors, A and B, make assertions into a Klee dataspace.
Background
The problem: We have an actor that has a rich internal model of some domain, and we want to use this model to generate a graphic design and render it to the user, how do we do this?
The (overly-simplified) answer: We build another actor!! Which listens for descriptions of shapes, and draws them to the screen. Now our original actor can make assertions of shapes, and the receiving actor will draw these descriptions.
For now I am calling this shape description language “Klee”. It is a programming language that will likely fall into the DOMain of shadows issue. But nonetheless I will try to make it a useful tool for using from any Syndicate implementation. It is roughly a mashup of ideas taken from the world of “display servers”, specific examples include:
The fundamental idea of Klee is that today’s vector graphics are highly dynamic. Take, for example, a graphic designer from the print-era, they would create a design for a single document size which gives the designer incredible control over the layout and parameters of their creation. Compare this to the modern website front-end designer, who needs to make a coherent design that is appropriate for screen widths of ~250px continuously to over 2000px, on all sorts of aspect ratios. The modern front-end designer no longer is constructing a design, but instead they are constructing a program to build a design given an arbitrary screen dimension. I figure creating a programming language for the definition of these “parameterized shapes” could be an appropriate tool for modern graphic design.
A Note on Syntax
Klee programs are not passed around as text representation. They are passed around purely as preserves structures that represent their AST and are serialized and deserialized per the preserves spec. As such, any recommended Klee editors should ideally work by making direct edits to the AST of the program, and not via some inhumane text representation.
In what world would it make sense to edit a highly structured AST using some bizarre text format?
Anyways, now that we got that out of the way, the Klee examples on this page will use a lisp syntax as it’s simpler for me than creating an AST to HTML converter to properly display programs.
A Basic Klee Program
(define (my-square)
(stroke 'red
(square 0 0 20)))
(view 'my-view 50 50
(box-layout
my-square
my-square))
This program defines a square shape called my-square and then uses this shape twice in a box layout (e.g. stacking the squares on top of each other), then draws this layout using the view function.
At a high-level, the entire point of Klee is to execute this view function as efficiently as possible, targeting at least 60fps. The individual function calls added to the view function will compile down to primitive draw operations, and these draw ops will be collected, encoded, and sent to the GPU for rendering. Optimization strategies like memoization of functions inside of the view call should allow us to build up scenes in an efficient way.