Stereo Tool
https://forums.stereotool.com/

Embracing Dear ImGui or other GPU accelerated UI library
https://forums.stereotool.com/viewtopic.php?t=29761		 Page 1 of 1
Author:  microdee [ Fri Dec 11, 2020 11:37 pm ]
Post subject:  Embracing Dear ImGui or other GPU accelerated UI library
Hi!

I love this software, using it daily. Throughout the years I've noticed it has become so packed with features the GUI starts to feel kinda clunky. As this software is not open-source to my knowledge I don't know which UI library is used or why the choice fell onto that one. But I can see many design choices have been made to minimize CPU time in drawing said GUI. That being said have the authors considered a GPU accelerated alternative? I've been working with Dear ImGUI and when I was coding with it I felt piece and love, it's incredibly easy to declare your UI in C++ with it. It's a stack-based "state-less" functional immediate mode UI library. It has almost 0 CPU impact while drawing really complex editor UI's with widgets all-over the place, at constant 60+ fps. What could be a really impactful improvement is to embrace Imgui's built in window docking and viewports feature. That would allow the user to open many of the features Stereotool offers at once and allow them to re-organize the layout of its windows like in Visual Studio for example, or any self respecting DAW.

If this would be open-source I'd try attempting myself, but the most I can do is to suggest it and offer my help (I'm also seeking a new job wink wink ;) ). The user experience would improve greatly, the application would feel butter-smooth and the CPU would not need to spend 5-20% of its time to draw the UI. Also by design ImGui doesn't have a backend preference. The app can fall back to previously used CPU-bound backends to draw the ImGui widgets if there's no graphics acceleration available.

I'm interested about the thoughts of the authors regarding this ;)
Cheers!
Author:  t.j.evers [ Mon Dec 14, 2020 2:29 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
We've actually been working on a new GUI for quite some time now!

It's a really large project, since we can't use existing frameworks or libraries for it: everything the UI does needs to be almost completely free of heap allocations.
We've looked into ImGUI as well. It would have been a lot easier if we could have used that...

The new GUI is pretty far along now. There's still a few essential functions missing, and it needs some optimizations, but it should be going to beta soon.

The fact that the application doesn't feel butter-smooth right now (I assume you're referring to the pretty visible screen tearing?) isn't even due to the GUI not being light.
It's due to a maximum amount of lines being able to be drawn before a redraw causes audible hiccups in the audio thread.

If you're interested in working at Thimeo, just contact Hans (hans@thimeo.com).

Kind regards,
Tom
Author:  microdee [ Mon Dec 14, 2020 4:10 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
Quote:
We've actually been working on a new GUI for quite some time now!
That is really great news!
Quote:
everything the UI does needs to be almost completely free of heap allocations.
Wow that is some major restriction, I didn't actually work on anything where heap allocation was mostly forbidden (discouraged sure, but not forbidden). Well I can only say good luck with your journey and looking forward to that GUI update ;)
Quote:
The fact that the application doesn't feel butter-smooth right now (I assume you're referring to the pretty visible screen tearing?) isn't even due to the GUI not being light.
It's due to a maximum amount of lines being able to be drawn before a redraw causes audible hiccups in the audio thread.
I didn't mean to downplay how effectively the already existing UI is drawn by the CPU, I can imagine it's already almost the fastest it could go. Obviously the hardware accelerated drawing would work around that maximum lines problem and other issues like that. By ImGui being butter-smooth I was referring to 60 fps+ output without artificial reduction of framerate to save CPU usage, almost no matter how many widgets you throw at it. But that would only apply to hardware with a GPU, I guess Stereotool needs to run on limited hardware too, where I guess a CPU backend for ImGui would then yield worse results than before.
Author:  Bojcha [ Mon Dec 14, 2020 6:03 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
I have almost ZERO knowledge about coding but i know how things need to work, look, and feel.

For example, Viber for windows uses OpenGL, and idk is it badly coded or what, but it makes problems in windows, especially when you play games. So usually users turns it off because of that. Even without anything moving that windows around causes stutters.
Other example is Telegram for windows. That thing uses something for GUI that makes ZERO negative impact on any windows and on any PC.

So point is in this case, programs like Stereo Tool need to work flawless with gui, with it's meters buttons, resizing, moving around. Also in this modern times should feel really smooth with those high refresh rate monitors. imagine how scope can look and feel at 144Hz and gui can deliver that.
Even in this current gui is clearly visible. 100% quality vs 150%.

Idk how will all look but i just hope for best solution.
Author:  MrKlorox [ Mon Dec 14, 2020 7:45 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
Quote:
For example, Viber for windows uses OpenGL, and idk is it badly coded or what, but it makes problems in windows, especially when you play games. So usually users turns it off because of that. Even without anything moving that windows around causes stutters.
This is how leaving BreakawayOne open on my second monitor makes games behave. Stereo Tool does not do this, but I minimize them both anyway. It would be nice to have an oscilloscope and with a small LUFS meter popped out that doesn't impact anything while I play games. But I'm fine with not monitoring things on my second screen while also being in a fullscreen mode on my primary monitor.
Author:  Bojcha [ Mon Dec 14, 2020 8:37 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
Quote:
Quote:
For example, Viber for windows uses OpenGL, and idk is it badly coded or what, but it makes problems in windows, especially when you play games. So usually users turns it off because of that. Even without anything moving that windows around causes stutters.
This is how leaving BreakawayOne open on my second monitor makes games behave. Stereo Tool does not do this, but I minimize them both anyway. It would be nice to have an oscilloscope and with a small LUFS meter popped out that doesn't impact anything while I play games. But I'm fine with not monitoring things on my second screen while also being in a fullscreen mode on my primary monitor.
I think that's more GPU problem with using 2 monitors. gForce cards have that problem for ages, especially if resolution is not same. I didnt notice single problem with Leif's softwares.
Author:  MrKlorox [ Tue Dec 15, 2020 1:03 am ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
Quote:
I think that's more GPU problem with using 2 monitors. gForce cards have that problem for ages, especially if resolution is not same. I didnt notice single problem with Leif's softwares.
Interesting. Yes the second monitor is a different resolution indeed. Perhaps something that detects Fullscreen or Borderless fullscreen modes and goes into a low impact GUI mode would mitigate this issue altogether.
Author:  microdee [ Tue Dec 15, 2020 5:46 pm ]
Post subject:  Re: Embracing Dear ImGui or other GPU accelerated UI library
I have 4 monitors on one nvidia card all with different resolutions, I have none of the issues you describe. Chat programs (including Vibe or Telegram) do not use OpenGL or any graphics backend for that matter (not directly at least). They use an application framework called Electron.js which is basically Chromium with extra accessories attached which in turn might use the same GPU acceleration as your regular Chrome does. It's the most wasteful but the quickest way to produce a communication software, so of course everyone is using it for their snowflake unique IM application. And most importantly their behaviour and speculating relations between that and screen-count has absolutely nothing to do with the original query.
Page 1 of 1 All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/