6 ms·

Another happy Audacity user here, great to hear it's going to get a refresh. My only request is that performance is kept top-of-mind - using Audacity is snappy

Another happy Audacity user here, great to hear it's going to get a refresh. My only request is that performance is kept top-of-mind - using Audacity is snappy and responsive even on ancient hardware, which makes it just a pleasure to use. UI interactions feel instant. The contrast to a slow Electron app like Slack is night and day.

ClumsyPilot 6y ago
Agreed, but thats the tragedy of desktop ui development. Either you get pretty but electron app where loading a few hundred messages grinds it to a halt Or you get ancient looking Ui Or you get platform spesific stuff! Actually Java applications are kinda reasonable compromise
- yellowapple 6y ago
  > Actually Java applications are kinda reasonable compromise As are .NET applications. Yeah, most .NET desktop apps in the wild are technically chock full of Windowsisms, I've found that said apps more often than not Just Work(TM) on e.g. Linux w/ Mono, and alternative toolkits like Avalonia help further.
- 177tcca 6y ago
  Material Design .NET applications okay?
marcan_42 6y ago
I've found the exact opposite - Audacity used to be instant, but these days its UI is dog slow. It seems to struggle badly on high-DPI displays: it is almost unusable maximized on both macOS and Linux (X11) if you have a 4K or so display. It feels like it's actively gotten worse on this front. I'm hoping this is something that improved in 3.0.0, because using Audacity is becoming increasingly impractical. I was just trying to listen to 10 tracks one by one yesterday and even just muting/soloing a track would take about a second; it was horrible. Shrinking the window helps, but it's silly to have a tiny window and scroll around when you have a 4K display. I kind of suspect this to be a windowing toolkit issue, and originally I thought it was macOS-specific (since I first noticed when I tried to recommend it to friends who use that), but ever since I moved to a 4K screen on Linux I noticed it's bad here too... The Mac story is here: https://forum.audacityteam.org/viewtopic.php?f=47&t=111105 https://forum.audacityteam.org/viewtopic.php?f=47&t=111105 The workaround is, well, not using HiDPI mode which is silly. But Audacity doesn't even seem to support HiDPI mode on Linux properly to begin with (the entire UI is small), so that's not it per se... I guess wxGTK just struggles when it has to draw 4x as many pixels? Apparently it's bad on Windows too: https://forum.audacityteam.org/viewtopic.php?t=111857 https://forum.audacityteam.org/viewtopic.php?t=111857
- Elv13 6y ago
  Those "classic" UI toolkit as raster engines. Both GTK/2/3 and QtWidgets 4/5/6 have OpenGL backends, but they are slower than the raster. This is because the state machine that drives the draw context is synchronous. Every line, pixels (or anything, really) takes some CPU cycles. Newer toolkits (QtQuick2, GTK4, Skia-based-ones) are hardware accelerated. They are slower of standard DPI, but much faster on HiDPI. So, yes, they cannot be as snappy on HiDPI, the number of pixel gets bottlenecked by the single thread performance of the CPU. Those barely grow year-over-year, while the number of pixel went up a cliff overnight.
  - floatboth 6y ago
    Where did you find an OpenGL render backend in GTK2/3?
    - Elv13 6y ago
      https://www.cairographics.org/backends/ https://www.cairographics.org/backends/ GTK -> GDK -> Cairo -> OpenGL
      - floatboth 6y ago
        Did anyone actually try to make that run in practice? I don't think GTK supports that. You can't just magically hot-swap Cairo backends externally. Using the GL backend means you provide GL surfaces to Cairo instead of memory.
        Elv13 6y ago
        It runs like crap, that's why it isn't supported. But if really, really want to make it work, you can have your app make a surface, put a cairo surface in it, then render GTK there. I suggest you don't waste any time on this. Mozilla, Google and Samsung had many people _each_ assigned to fix it at some point. The Google gave up, bought Skia. Then Mozilla also gave up and used the now Open Source Skia. Samsung somehow kept poking at it for a few more years until they dissolved their Open Source division and scaled down Tizen. At some point Samsung make a Vulkan backend for unknown reasons. With Qt 4/5, there is an environment variable, to play with. It sill runs like crap and is now deprecated. edit: Of course, GTK4 have "real" backends for both Vulkan and OpenGL. They implement scene graphs like QtQuick rather than building a big bitmap like GTK2, GTK3 and QtWidgets.

ClumsyPilot 6y ago

Agreed, but thats the tragedy of desktop ui development. Either you get pretty but electron app where loading a few hundred messages grinds it to a halt Or you get ancient looking Ui Or you get platform spesific stuff! Actually Java applications are kinda reasonable compromise

yellowapple 6y ago
> Actually Java applications are kinda reasonable compromise As are .NET applications. Yeah, most .NET desktop apps in the wild are technically chock full of Windowsisms, I've found that said apps more often than not Just Work(TM) on e.g. Linux w/ Mono, and alternative toolkits like Avalonia help further.
177tcca 6y ago
Material Design .NET applications okay?

marcan_42 6y ago

I've found the exact opposite - Audacity used to be instant, but these days its UI is dog slow. It seems to struggle badly on high-DPI displays: it is almost unusable maximized on both macOS and Linux (X11) if you have a 4K or so display. It feels like it's actively gotten worse on this front. I'm hoping this is something that improved in 3.0.0, because using Audacity is becoming increasingly impractical. I was just trying to listen to 10 tracks one by one yesterday and even just muting/soloing a track would take about a second; it was horrible. Shrinking the window helps, but it's silly to have a tiny window and scroll around when you have a 4K display. I kind of suspect this to be a windowing toolkit issue, and originally I thought it was macOS-specific (since I first noticed when I tried to recommend it to friends who use that), but ever since I moved to a 4K screen on Linux I noticed it's bad here too... The Mac story is here: https://forum.audacityteam.org/viewtopic.php?f=47&t=111105 https://forum.audacityteam.org/viewtopic.php?f=47&t=111105 The workaround is, well, not using HiDPI mode which is silly. But Audacity doesn't even seem to support HiDPI mode on Linux properly to begin with (the entire UI is small), so that's not it per se... I guess wxGTK just struggles when it has to draw 4x as many pixels? Apparently it's bad on Windows too: https://forum.audacityteam.org/viewtopic.php?t=111857 https://forum.audacityteam.org/viewtopic.php?t=111857

Elv13 6y ago
Those "classic" UI toolkit as raster engines. Both GTK/2/3 and QtWidgets 4/5/6 have OpenGL backends, but they are slower than the raster. This is because the state machine that drives the draw context is synchronous. Every line, pixels (or anything, really) takes some CPU cycles. Newer toolkits (QtQuick2, GTK4, Skia-based-ones) are hardware accelerated. They are slower of standard DPI, but much faster on HiDPI. So, yes, they cannot be as snappy on HiDPI, the number of pixel gets bottlenecked by the single thread performance of the CPU. Those barely grow year-over-year, while the number of pixel went up a cliff overnight.
- floatboth 6y ago
  Where did you find an OpenGL render backend in GTK2/3?
  - Elv13 6y ago
    https://www.cairographics.org/backends/ https://www.cairographics.org/backends/ GTK -> GDK -> Cairo -> OpenGL
    - floatboth 6y ago
      Did anyone actually try to make that run in practice? I don't think GTK supports that. You can't just magically hot-swap Cairo backends externally. Using the GL backend means you provide GL surfaces to Cairo instead of memory.
      - Elv13 6y ago
        It runs like crap, that's why it isn't supported. But if really, really want to make it work, you can have your app make a surface, put a cairo surface in it, then render GTK there. I suggest you don't waste any time on this. Mozilla, Google and Samsung had many people _each_ assigned to fix it at some point. The Google gave up, bought Skia. Then Mozilla also gave up and used the now Open Source Skia. Samsung somehow kept poking at it for a few more years until they dissolved their Open Source division and scaled down Tizen. At some point Samsung make a Vulkan backend for unknown reasons. With Qt 4/5, there is an environment variable, to play with. It sill runs like crap and is now deprecated. edit: Of course, GTK4 have "real" backends for both Vulkan and OpenGL. They implement scene graphs like QtQuick rather than building a big bitmap like GTK2, GTK3 and QtWidgets.