EnsoGL API for Shape and Display Object Ordering

[MichaelMauderer]

Yes, the current interface to layer symbol partitions (i.e. exposing them directly) is very low-level. During the next draw-calls push I intend to put it behind a more convenient abstraction (that could eventually be used to unify the 3 layering mechanisms, and instead distinguish inside-component relationships and between-component relationships). Until then, hard-coded partitions are ugly but they save draw calls.

Originally posted by @kazcw in #6483 (comment)

I think ideally we should allow the relationships to be defined between instances of shapes, but also display objects. Both should be first class entities in our “define order” API.

A common use case would be when creating a new UI component that is based on existing components: there might be a background shape, that is supposed to be behind everything, a number of already existing display objects, that need to be above the background, and in a specified order between each other. And since we are moving towards heavy re-use of the shapes (through the super rect, for example), this will need to handle the same shape in different instances with different constraints.

Currently, we are hacking around these constraints by generating many layers in our HardcodedLayers struct and UI elements internally place components on specific layers. But the more complex our UI gets, the more this is bound to fail, as we compose UI elements and they need to behave nicely in different contexts.

My last use case was that I was trying to re-use a dropdown in the panel layer. But this was problematic, as the dropdown puts the text on a separate hardcoded layer. This prevented simply putting the dropdown into another layer, and instead required adding a new API for independently also setting the layer of the text.

In essence, we should have an API that allows display objects to be self-contained regarding their layer placement and not require an external API to set different subcomponents to separate layers to preserve correct ordering.

[wdanilo]

CC @kazcw. This is not high-priority now, as high-priority are the performance fixes, but we need to chat with Kaz about the high-level API here.