GUI redraw issues
SpacemanPaul opened this issue · 4 comments
When switching between tabs or out of the "modulation chooser" dialog, various parts of the GUI are often not immediately redrawn, and you need to drag the window off the screen and back to force a redraw.
I did not notice this, though I'm aware that the GUI on Linux is slower than I'd like it to be.
However, there are 2 things that I'm aware of which can affect the GUI's responsiveness badly:
- 32-64 bit bridging, e.g. if you are running the 32 bit version in 64 bit Reaper.
- The awful trick in the FST (VST 2) version for handling X11 events.
As far as I know, VST 2 never officially supported Linux, which is probably why I was unable to find an "official" way for handling GUI events like redraw, click, mouse move, etc. On Windows, a program can register its event handler to the operating system, which will run it immediately when any kind of user interaction occurs. On Linux and X11, you get an FD from which read GUI events, and the application's main loop is supposed to immediately read and process these when new events appear on the FD. So far so good.
The problem is that plugins don't get their own GUI threads on Linux, so they can't read the events from the FD synchronously with blocking I/O, otherwise the DAW's GUI would freeze. And since originally, VST 2 plugins were not intended to run on linux, the VST 2 standard doesn't have a way to nicely blend the DAW's and the plugin's event handling either.
I guess a plugin could try to launch its own GUI thread, but that could interfere with the host in so many ways, and it would be so error-prone, that I'm not even sure it's worth even considering this option.
The only thing a VST 2 plugin can do on Linux is to kind of misuse the effEditIdle callback: a VST 2 host is supposed to periodically send this message to the plugin in the GUI thread (around 20-30 times per second), so that plugins can update their GUIs in response to this (e.g. update volume meters, etc.) And since there are no better options, this callback can also be used for processing X11 events. But this way, what normally happens in a Linux application immediately, will experience a 40-50 milliseconds lag, which can add up and become noticable when complex interactions are composed of multiple events. (E.g. closing one window, and as a consequence, redrawing another.)
I'll take another look at the plugin's event handling to see if I can find ways to squeeze some more responsiveness out of it, but I'm afraid it will never be perfect due to these limitations.
Yes. this is on Linux. 64bit VST2.4 plugin in Ardour.
This is weird: Ardour 5.12.0 seems to send an effEditIdle message before the effEditOpen when it attempts to open GUI, which makes JS80P crash immediately, because the GUI is only initialized when the effEditOpen message is delivered.
After fixing that, the GUI seems to render okay for me. What version of Ardour are you running?
Not enough info for reproducing the problem, no response either.