Displaying the reference frame selector has a significant performance impact

[Growflavor]

TL;DR: On @Growflavor’s machine, opening the reference frame selectors degrades the framerate from about 60 FPS to about 15 FPS. Opening other windows also impacts the framerate, albeit less so.

Original issue below.

---

I mentioned on the forum the primary issue of UI lag with the recently revised reference frame selector UI even on my primary machine that uses an NVIDIA RTX 2070S GPU.

Per eggrobin's suggestion at the forum that there might be a way to reduce the UI's impact on performance, I am opening this issue to report/track significant Principia UI FPS performance impact primarily with the new reference frame selector.

I also suggest this FPS method as a simple proxy to observe the relative impact of various parts of a UI which might help to identify elements that currently produce the most impact. For example, 'pinning' the desired frame row & collapsing the full option tree noticibly reduces the FPS impact of the new reference frame selector UI.

Consequently, I am also hopeful that this UI impact via FPS observation method might help lead to insights that may also reduce the performance impact of the Flight Plan UI.

Link to linuxgurugamer's handy FPS tool: https://forum.kerbalspaceprogram.com/index.php?/topic/172692-112x-showfps/

Here is an example screenshot of the FPS impact of one of the new reference frame selector UIs, examples of other UIs may be viewed in the album provided later in this post:

Album of screenshots showing the relative FPS impact of various Principia UIs or combinations of UIs:
https://photos.app.goo.gl/xGtHaFaZvUS26KBU6

Hopefully at least some amount of relative FPS impact replicates on your machines. Please let me know if there is further information that may be useful to you. Thank you for the new reference frame selector UIs. I hope this concept of FPS metric ends up useful to help identify ways to reduce the impact of various Principia UIs on performace.

[eggrobin]

Edited and renamed the issue to focus on the actual bug, not the (somewhat overkill) methods section.

The issue is readily reproduced.

The culprit is probably the localization logic, which, given that the set of celestials is unchanging, could probably be cached to a large extent.

Caching would be trickier in the flight plan, where many placeholders hold durations or Δvs rather than discrete types.

[pleroy]

There is a MemoryCache in .Net which would presumably work for all our needs.

[rjeli]

yeah, dragging right click generates a few thousand imgui events, which choke mostly on Localizer.Format. but even with perfect caching there's quite a bit of time spent otherwise, too much for 60fps. doesnt look like theres a way to throttle unity imgui events, or cache the drawn window (to only rerender at 10hz or so). hmmm

[rjeli]

anyways, a tiny lru cache should get rid of the 10 second frames, maybe with throttling/caching of flight plan values if they update >1000hz (probably?)

[rjeli]

oh maybe this can be used to do less repaints

https://docs.unity3d.com/2020.2/Documentation/ScriptReference/EditorWindow.html

[eggrobin]

dragging right click generates a few thousand imgui events […]
quite a bit of time spent otherwise
cache the drawn window
[fewer] repaints

This issue is about the performance degradation introduced in Haar, which comes from the localization logic, and blatantly manifests itself even when one is not interacting with the UI.

The frequency of rendering is entirely out of scope here; that has never changed and was never much of an issue (until rendering started taking ages because of the localization logic).

(Of course it is the entirety of CelestialString which should be cached, not the innermost Localizer.Format: CelestialString is just our own—fancier—localization logic).

[rjeli]

Of course it is the entirety of CelestialString which should be cached

Sorry, my build wasn’t fully instrumented - about half the time of ReferenceFrameSelector.RenderWindow is spent in CelestialString and about half in direct calls to Localizer.Format