You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Capturing issue reported via email from Viktor Engelmann.
Automaton sizing/layout is captured in pixels which results in issues for high-DPI displays. Need a more display-agnostic approach to storing/restoring layouts and determining sizing.
Unfortunately, I don't have any high-DPI displays to test and debug the issue.
The text was updated successfully, but these errors were encountered:
Something that would help would be to translate state coordinates to be relative to the start state on serialization, then translate them back to parent-element left/top on display. This would at least make the serialized descriptions more predictable.
I played with storing start-state relative coordinates when serializing, but that runs in to issues where states can be rendered at positions less than 0 when loading on a different screen, which means you can't access them at all.
I played with storing locations as a percentage of the container, but the container can scroll, so on deserialization the graph would shrink in to the available space. If I also captured a container size the calculated result would be equivalent to storing the absolute positions that I already use.
For now I'm not doing anything to address. I need a workable solution.
Capturing issue reported via email from Viktor Engelmann.
Automaton sizing/layout is captured in pixels which results in issues for high-DPI displays. Need a more display-agnostic approach to storing/restoring layouts and determining sizing.
Unfortunately, I don't have any high-DPI displays to test and debug the issue.
The text was updated successfully, but these errors were encountered: