I did a bit of research but didnt find much...
Maybe you just have to implement a multitasking system of some sort for your rendering system, such that you can render the scene and UI at different rates.
-Scene and UI are both rendered to off screen buffers (with ping pong buffering or whatever you need to keep it smooth)
-At 60 FPS you merge the contents to the actual backbuffer and display
So if the scene draw is going at 2 FPS, it just means you will be copying the same rendered scene to the scene for about 30 frames, while the UI will remain interactive (assuming it can do 60 FPS)
You can optimize by drawing UI directly to backbuffer on top of the copied scene render (so UI render is tied to the 'main' 60 FPS rendering)
Now, how to actually separate the scene rendering from the stable 60 FPS render, Im not sure.
-Maybe multithreaded/multicontext (I dont even know if those are the same thing) rendering allows decoupling them?
-Maybe you can sprinkle 'check-if-60-FPS-UI-render-should-be-done' calls in the middle of the scene render:
2. Check if UI + latest scene render should be drawn to maintain high FPS
4. Check if UI + latest scene render should be drawn to maintain high FPS
6. Update latest scene render buffer and draw it + UI
(If you didnt do this, it would just be sequential and be as slow as scene render FPS)
Im pretty sure the end result is going to be jittery graphics and unexplained 50% performance loss...
Maybe theres a way to make the OS do the prioritization, but I suspect it only works for OS internals (whatever draws the OS graphic thingys), so maybe it would only work if you do rendering on CPU and use some OS call to blit that to the window... Or some transparent child window on top of the game scene area... ew...