Closed sylwiabr closed 6 months ago
That isn't very pleasant to fix, as it requires a separate layer per visualization type. With a recently introduced API for shape ordering, it can be simpler, though. @MichaelMauderer @kazcw, you might have some helpful advice here.
Layer per visualization is a bad idea, it will kill the performance. New layers are also not a solution here. If both visualizations are in HTML/JS this is fixable. If one of the visualizations (or its text) is in WebGL, I think this is wontfix. I don't like it, but either we have this or way worse performance :(
In this specific case, it might be easier, as both of them are JS visualization using HTML elements. As are most of our visualizations, and the backgrounds. So this might be easy to "hotfix". But the general case for EnsoGL visualizations might be tricker, as we'd want the background of each instance to occlude the whole other visualization.
If both visualizations are in HTML and their backgrounds are in HTML as well, then yes, this should be fixable. But I think this is low-priority now, taking into consideration other bugs we have.
Not relevant to GUI2.
Discord username
No response
What type of issue is this?
Permanent – Occurring repeatably
Is this issue blocking you from using Enso?
Is this a regression?
What issue are you facing?
Expected behaviour
Proper Z ordering for different types of visualizations.
How we can reproduce it?
No response
Screenshots or screencasts
No response
Enso Version
Nightly 02.05
Browser or standalone distribution
Standalone distribution
Browser Version or standalone distribution
standalone
Operating System
MacOS
Operating System Version
No response
Hardware you are using
No response