Slow GUI response on Track Control Panel


Just noticed a painfully slow response to moving over and clicking on the Track Control Panel buttons (Mute, solo, balance, etc) - It is taking almost 1 full second to update the control animations when hovering or clicking on them.

This seems rather superfluous to me. Do we really need an animation here? Other buttons I regularly use work fine without doing this animation thing.

Can I turn this ‘feature’ off?

I noticed this after installing the Flatpack (not a huge fan, tbh) package (I had to upgrade due to the AAC encoding error). I didn’t notice it in the previous version, 2.2.x iirc.

My OS is Linux Mint 19.3
Audacity v2.4.2

Many thanks.

The buttons don’t have “animations”, they are either up or down. :confused:

I built Audacity 2.4.2 from the source code (which appears to be the only way to get a fully functional version of Audacity 2.4.2 on Linux at the moment) and the Solo / Mute buttons react instantly to clicks.

Thanks for your input, Steve :slight_smile:

Apologies for confusing the issue. I didn’t mean to infer there was a delay in clicking these controls, just a complete lack of responsiveness whilst it renders the new state of those particular buttons. For example, when I click ‘Mute’, it mutes as expected, however, when I move off it, Audacity’s interface stops updating for ~500ms until this button changes it’s appearance.

Maybe not animations, not that I saw any frames, but they seem to be decorated with a subtle effect on my desktop. I will add a picture - It certainly doesn’t seem like a simple background colour change. It seems like a scaled, anti-aliased, light-grey circle in the light theme.
There appears to be shading/graded colour around the inside edges of the button.

I noticed that CPU usage peaks at 25% (1/4 of my quad-core) when continually mousing-over these controls, instead of the usual 2-3%, when idling or mousing over other controls. Also, on closer inspection, there seems to be an effect applied when hovering over the button, though there is this same minor effect on the other buttons they don’t hog my CPU. If it was my window manager, I would expect all buttons of that style to behave the same.

As mentioned, the slowdown affects Audacity’s entire interface, so whilst these buttons are being ‘drawn’, Audacity doesn’t update at all.

Neither changing the theme nor blending the system theme changes anything, though I do like the dark theme.

Out of curiosity, in the source code, do you know if those buttons are in any way rendered, designed or instantiated differently to the other buttons in the main window’s interface? I would think that they have to be dynamically created for each audio track whereas the transport controls don’t. Are they handled in an array or evaluated in a way which makes them heavier than their brethren? :confused:

I also have an issue with the interface update rate - I am getting about 2 FPS from this Flatpack version when scrolling and playing back. Basically, any interaction in the tracks area is severely sluggish.

I think the previous version was v2.3.3 (I have since uninstalled and changed to v2.4.2 as advised, but I didn’t record the previous version number.)

Also, there seems to be redraw(?) issue with the horizontal scrollbar after zooming and playing it seems to come disconnected from the sample position and snaps to it’s real position on mouseover. Not sure if this can be caused by my window manager, but not sure how to rule that out. However, I am sure I would have had issues in other programs if Audacity is doing nothing out of the ordinary with it’s window’s controls :confused:

Would you have any ideas on how to check what are causing these issues? I don’t know how to trace interface performance issues in Linux. Is there anything which can analyse callback/function times, etc for the program? Again, I haven’t done any serious coding on Linux, so not sure of the state of play in that regard.

I could just go and change some settings until it [possibly] works, but I know that Linux can become troublesome if one unwittingly changes incompatible settings. I may change my window manager, but all that would tell me is that I can’t use Audacity with Compiz. Since I have a productive desktop set-up, I don’t want to sacrifice my window manager.

There must be something particular to those controls which makes them an issue. But I maybe the proverbial dog with a bone lol

Hope the above helps explain things in a bit more detail.

Thanks again.

I’ll give that a go.

Thank you :slight_smile:

Are you working with extremely long tracks (hours of audio) and / or a high res monitor?
Redrawing the waveforms can be slow in such cases (and the Mute button causes the waveform to be redrawn).

The track’s control panel is created as a lightweight widget, so it seems unlikely that the issue is the button itself.