Multiple "streams" for graphical data, click targets, snap targets, gizmos, and parameter widgets?

Inspired by the ideas in Blender's way of representing gizmos: https://www.youtube.com/watch?v=Opzk1wUhzCw

Currently, a node network (graph/subgraph) processes the graphical data, such as `Table`. This is what will become the "graphical stream". But this graphical data it is also abused by the tooling, which needs to track the graph data for interacting with it. Some nodes (like the Text node) need custom control over their click targets.

The idea here is to add extra "graph streams" to the same subgraph, which lets the user pick from a dropdown menu which stream to show nodes for. The graph's data imports would likely be the same in all streams, but its exports would be of different types. However, they would all be nodes in the same subgraph and it will probably be possible to Shift click multiple dropdown menu entries to see them simultaneously, otherwise when one isn't shown its nodes and exports are simply hidden from the subgraph.

- Click targets: the exports would be some vector description of click targets used for hit testing. It would likely be stored as an additional table on the graphical data type flowing through the graph. If present, that table overrides the click targets in use (otherwise it falls back to the geometry of the `Vector` content or some alpha cutoff threshold for `Raster` content). The Text node or others may add a table for custom click targets using nodes in this graph stream. Other nodes, like Bevel or Path (which fundamentally change the geometry) may choose to delete any such table because it would become invalid. Other nodes (like Transform) may apply its change to the click targets table.
- Snap targets: similar to click targets but these would be various types of snapping targets with different classifications for things like importance, geometric form, etc. Dynamic targets could be returned by evaluating this graph stream in different scenarios or with different snapping settings or priorities set.
- Thumbnails: some nodes may wish to offer a custom thumbnail render, or bounds. That'll be necessary for nodes which produce boundless data. This might be able to be consolidated into another concept instead of using a separate stream.
- Gizmos: these might be part of click targets? It remains to be determined how much they take over from what's currently handled by the tools in regards to displaying gizmos.
- Parameter widgets: the UI for each node's parameters in the Properties panel is currently either derived in the most trivial cases or is linked by name to a hard-coded layout definition function. That link is fragile since any change to the node definition unlinks it. The solution is to move those hard-coded layout definition functions into the graph itself. A family of nodes representing the widgets and various logical operators and math functions can be used to replicate all existing methods of defining the layouts. In the future, we can even have a drag-and-drop widget builder in the editor UI which builds this node graph behind the scenes on behalf of the user, just like viewport tooling edits the graphical parts of the graph.

A future opportunity, which doesn't have to be implemented initially, is that the graph can be compiled by the Graphene compiler omitting any streams that aren't relevant. In a CLI environment, editor-focused things like click targets may not be needed (unless they are used for something interactive at runtime like hit testing). And we can even decouple the render from the click targets and gizmos, keeping the editor and overlays/gizmos responsive even if the artwork renders at a considerably lower framerate. This will make painting much more feasible and all sorts of design feel snappy by letting overlays fill in the gaps. Even the visualization stream can first render using a low quality level, then if there's time before the next frame is requested, go back and do a medium and then a high quality render (with all those renders happening on a version of the graph containing only the graphical data).

Commencez par examiner le réseau de nœuds, le sous-graphe et le flux de données graphique décrits dans l’issue, notamment la manière dont les imports et les exports sont actuellement représentés. Définissez la portée et la représentation des streams proposés, puis validez la conception par rapport aux cibles de clic, aux cibles d’aimantation, aux miniatures, aux gizmos, aux widgets de paramètres et aux cas d’utilisation du compilateur Graphene.

Rédigé par le modèle d'indexation à partir du texte de l'issue.