search

ZL-Audio / ZLEqualizer

equalizer plugin
https://zl-audio.github.io/plugins/zlequalizer/
GNU Affero General Public License v3.0
309 stars 8 forks source link

GUI and host very low performance since JUCE updates(?) #49

Open mikelupe opened 7 months ago

mikelupe commented 7 months ago

On Linux (Debian/KDE/X11) there is a massive graphics lag with the plugin (concerning as well the host's Ardour GUI) since about a week.

It must have happened in the past week, but I'm not sure if it was after d72acee or only after 23f4fcd . I guess the probability is high that it could be related to the JUCE update, what do you think?

zsliu98 commented 7 months ago

I also observed graphics lag on macOS after the commit 3bafe86cfd7dc3d2b3d42c14ab19e935354c88fb, i.e., updating to JUCE 8. If it is the same case for you, it must be due to this JUCE major update. I will try to figure it out and report it to the JUCE team. Hopefully, they can fix it then while adjusting/explaining the new EULA :astonished: There is also an increase in the final binary releases :) don't know why either, but also seems problematic

zsliu98 commented 7 months ago

I have just created a juce7 branch (the only difference is JUCE itself and one line JUCE8 related code). Would you like to try the juce7 branch if you have time?

mikelupe commented 7 months ago

I just built the juce7 branch and it still feels and looks very laggy. I as well can hear the CPU fan running higher.

zsliu98 commented 7 months ago

I just built the juce7 branch and it still feels and looks very laggy. I as well can hear the CPU fan running higher.

Did you observe the lag when dragging/changing a filter? Or the lag happens even if nothing is done (e.g., only several static filters with FFTs)? It is strange cause the UI-related code (of this repo) hasn't changed that much since last week ... BTW, did you also update submodules when checking out the juce7 branch?

mikelupe commented 7 months ago

That was it - I now cleaned and repulled everything -> lag is gone.

zsliu98 commented 7 months ago

That was it - I now cleaned and repulled everything -> lag is gone.

Then it is a JUCE 8 issue. And it is the same on my macOS. I will report it to the JUCE team.

mikelupe commented 7 months ago

Let's cross fingers

mikelupe commented 7 months ago

btw I only tested VST3 under Linux with JUCE8 - I could test LV2 with it as well tomorrow.

zsliu98 commented 7 months ago

btw I only tested VST3 under Linux with JUCE8 - I could test LV2 with it as well tomorrow.

No need to do that. Both VST3 and AU have the same issue. LV2 won't be the lucky one. BTW, I have also removed some dirty & unsuccessful workarounds from branch juce7. You may pull & build again if you use this plugin.

mikelupe commented 7 months ago

Commit c32637c in "main" is juce8? Because it feels quite snappy now...

zsliu98 commented 7 months ago

Commit c32637c in "main" is juce8? Because it feels quite snappy now...

Unfortunately, it is JUCE 7 :sweat: I will stick to JUCE 7 in the next (few?) months since the bugs in JUCE 8 make me painful.

mikelupe commented 7 months ago

Haha - good choice :) You've got a chance to find time concerning realtime safety in the near future?

zsliu98 commented 7 months ago

Haha - good choice :) You've got a chance to find time concerning realtime safety in the near future?

The real-time safety issue should be solved in 0.1.14. Have you experienced crashes or audio pops/clicks since then? The rendering issue (when automation is activated) is nothing related to real-time safety. It is because the plugin and the DAW are both using CPU to render (and for some reason in the same thread). According to advertising, JUCE 8 Webview can obtain instant cross-platform hardware accelerated graphics via WebGL. But I am afraid that the whole Webview thing still needs some time.

mikelupe commented 7 months ago

I see - I indeed thought the missing rt safety was the reason for the host UI lagging when moving the EQ points. No, I haven't got any pops nor clicks.

Well, it is what it is. I'm not sure I'd be too keen on WebGL. But I though even with juce7 it should be possible to multithread it, it really is strange.

Anyway, thanks for your efforts again.

zsliu98 commented 7 months ago

In the pre-release 0.2.0 (main branch), I have moved the majority part of the calculation to a background thread. However, there is no way to multithread the paint() function AFAIK. Does it solve the host UI lagging under the Lowest Refresh Rate (in the UI setting panel)? You can double-click the top-left logo until a UI button appears at the top-right.

mikelupe commented 7 months ago

Funny enough, that's exactly what I tried some 2-3hrs ago, as I saw you integrated the refresh rate. And yes, on lowest it helps indeed.

Do you think you'll find a solution for the threading thing in the next few weeks or months? It would really be a pitty, if this would hinder it to become one of the contenders of plugin of the year :)

Thanks for your work

zsliu98 commented 7 months ago

Funny enough, that's exactly what I tried some 2-3hrs ago, as I saw you integrated the refresh rate. And yes, on lowest it helps indeed.

Do you think you'll find a solution for the threading thing in the next few weeks or months? It would really be a pitty, if this would hinder it to become one of the contenders of plugin of the year :)

Thanks for your work

Pre-release 0.2.0 not only integrates the refresh rate but also puts the majority of path updating to a background thread (you may pull the code again since there have been several commits in the last few hours). And you may increase the refresh rate until the host is not happy with that. AFAIK, there is no way to multithread the paint() function (which now only contains g.strokePath() or something alike). The only way to make g.strokePath() faster is to use hardware acceleration (on Linux, it means OpenGL/WebGL).

mikelupe commented 7 months ago

Yeah, that's what I did, and it felt indeed smooth, I already had played around with the different levels of refresh rate, and as mentioned it indeed helps.

The only way to make g.strokePath() faster is to use hardware acceleration (on Linux, it means OpenGL/WebGL).

You already explained that , my bad.

zsliu98 commented 5 months ago

A quick update: I have bumped JUCE to JUCE 8 and it works OK on my local macOS and Windows. I have also adjusted the GUI part a little bit, which may improve the performance (especially during automation).

You may build it locally (make sure you also update JUCE) or download the pre-release 0.3.2.

mikelupe commented 5 months ago

Unfortunately under Linux the performance is worst case again here, even without automation. As soon as I try to open the GUI, everything stalls. Refresh rate is already set to 25fps. I pulled everthing incl. JUCE. Maybe I'll find some time to check closer on it this weekend.

mikelupe commented 5 months ago

Unfortunately I do have this on two different machines - stalling is quite strong, more or less the same as when you had it on Mac. There must be a way. What opengl and Mesa (on Mac? no idea) library versions do you have installed?

zsliu98 commented 5 months ago

Unfortunately I do have this on two different machines - stalling is quite strong, more or less the same as when you had it on Mac. There must be a way. What opengl and Mesa (on Mac? no idea) library versions do you have installed?

Thanks for the feedback. The Metal version of my macOS is Metal 3.

Would you like to try the branch juce7 when you have time? (or the binary from https://github.com/ZL-Audio/ZLEqualizer/actions/runs/9553093036) Currently, I am still uncertain about the cause of the stalling (JUCE 8 or some improvements? I have made in 0.3.2).

BTW, does the previous version 0.3.1 have the stalling issue?

mikelupe commented 5 months ago

The stalling only came back with 0.3.2.

mikelupe commented 5 months ago

I just rebuild the juce7 branch and there it's ok (without automation, the stalling there remains when automating)

zsliu98 commented 5 months ago

I just rebuild the juce7 branch and there it's ok (without automation, the stalling there remains when automating)

It is an awkward situation. JUCE 8 has GUI issues on Linux while JUCE 7 GUI does not perform well on Windows ... Perhaps I shall build with JUCE 7 for Linux and build with JUCE 8 for Windows and wait for JUCE to solve this problem in 8.0.1 :worried:

mikelupe commented 5 months ago

That's an awful situation and quite painstaking for you to handle, but it could be the best. Is the JUCE "team" already aware about these issues?

zsliu98 commented 5 months ago

That's an awful situation and quite painstaking for you to handle, but it could be the best. Is the JUCE "team" already aware about these issues?

I reported it in April ... maybe they have been aware of this. Cause I can't read the low-level GUI code, I am not able to provide a detailed report to them.

mikelupe commented 5 months ago

Maybe you could approach https://github.com/baconpaul , he's strongly involved in several projects like https://github.com/surge-synthesizer/surge , https://github.com/surge-synthesizer/shortcircuit-xt/commits/main/ and helps Airwindows' Chris out with https://github.com/baconpaul/airwin2rack/ . I don't know him personally, but I think he's quite JUCE affine - you never know :)

mikelupe commented 4 months ago

Lately building the juce7 branch with git checkout 7.0.12 in the JUCE directory under Linux gives similar/same bad performance like when building the juce8/main branch. What could potentially happen here?

I cleanup the git folders, so am cloning anew to be sure. Very strange

zsliu98 commented 4 months ago

Lately building the juce7 branch with git checkout 7.0.12 in the JUCE directory under Linux gives similar/same bad performance like when building the juce8/main branch. What could potentially happen here?

I cleanup the git folders, so am cloning anew to be sure. Very strange

0.3.3 does not touch the GUI part (except add a button in the General setting). Besides that, the size of the binary release also indicates that it is on the same juce7. If you have time, you may try the following things:

mikelupe commented 4 months ago

My bad, after pulling the juce7 branch and checking out JUCE 7.0.12, I then did a "git submodule update --init" which I guess reset JUCe to the default 8 again. Sorry the noise, it's back to normal performance.

Still, couldn't you bind the submodule to automagically checkout 7.0.12 in the juce7 branch? There wouldn't be the need for another version in that branch, or would it?

zsliu98 commented 4 months ago

My bad, after pulling the juce7 branch and checking out JUCE 7.0.12, I then did a "git submodule update --init" which I guess reset JUCe to the default 8 again. Sorry the noise, it's back to normal performance.

Still, couldn't you bind the submodule to automatically checkout 7.0.12 in the juce7 branch? There wouldn't be the need for another version in that branch, or would it?

If both branches have the same submodule version, the pull request will be easier. But I do see the building process might be confusing. I have changed it to 7.0.12 now.

mikelupe commented 4 months ago

Thank you - that works fine, just tested.