Plotter Redesign

[termi-official]

The current pipeline reflects the straing forward way of rendering with makie, but is also peak inefficiency. When the topology interface is merged my new idea is to have a more modern pipeline based around culling, as found in game engines, and filters, as for example found in paraview. However, I still struggle with the details.

I start with a short outline on what I know and how I want to design it.

1. I believe that the pipeline should be element-centric. I think this has several advantages over the "semi-global" perspective as we have now, altough the implementation will get more complex. In 3D this allows us to efficiently detect which faces should be rendered and which can be discarded (by utilizing the face-neighborhood) and only these will be added to the "list of rendered triangles". This decoupling is not only necessary for efficiency, but also for cuts though the domain to inspect the interior. Further, we can either apply a software tessellation or a hardware tessellation.
2. Maybe it makes sense to delay the triangulation until the actual rendering happens. This way we could design something like this for some hypothetical FSI problem:

Plotter(grid,dh) |> Subdomain(cellset1) |> Cut(point,normal) |> Deform(var=:d) |> Wireframe() |> Surface(var=:d, proc=l2) |> Render()
Plotter(grid,dh) |> Subdomain(cellset2) |> Cut(point,normal) |> Deform(var=:d) |> Wireframe() |> VectorField(var=:v, symbol=:arrow, proc=id) |> Render!()

Which I would like to yield a look into the deformed mesh while also seeing the deformed wireframe. Caching could be introduced by passing copies on each subsequent call. *! variants are then allowed to bypass this copying. Render! is a way to tell the backend to render into the same (graphics) buffer.
However, I am a bit lost on how to keep the triangulation in sync. Maybe it is required to have a "shadow" of the grid here, i.e. some element-wise metadata. But this then can become quite expensive once we have several different. Maybe we should take a look on how exactly the ParaView filter architecture works to learn from it.
3. Maybe we could also get away with a change in the actual interface. We could have some basic primitives, as for example surface and wireframe, which appect some optional filters. A possible categorization would be into "topological", "geometrical" and "data transform" filters, where cutting the mesh open would be an example for a topological filter, deforming the mesh would be a geometrical one and extracting a component to colour a surface would be a an example for the data transform. Alternatively we could think about how we could make an interface which directly applies to the plotter object.

Feedback pls @koehlerson .