GUI startup delay under X11

[Krasjet]

I notice that any GUI plugin built with DPF seems to have a significant start-up delay on Linux. This problem is especially noticeable in REAPER, where the GUI is deconstructed and reconstructed every time you float/dock the plugin (by double click on the plugin in the chain on the left) or switching between plugins

In Ardour, the GUI is only constructed once so the problem is less problematic.

I can notice the delay in both the example plugins (compiled with develop branch) like d_states and third party plugins like the dragonfly-reverb.

The only example plugins that doesn't have this problem is d_embedextui, though I don't think I can see the GUI been rendered

Right now, what I know is

1. JUCE plugins don't appear to have this problem.
2. There is also no such delay on Windows.
3. It affects all plugin formats and the standalone.
4. I can reproduce the problem on multiple machines running Debian Sid, Haven't tried another distribution though.

I'll post more info when I locate the problem, but I want to post the issue in advance in case this is a known problem. Has anyone noticed this problem before?

[falkTX]

I did not notice anything in regards to delay at all, for me it works just like any other gui framework/toolkit.

i do not even understand what you mean by delay here... gui opens but first render takes a while? host daw is locked up temporarily while gui opens..? how big of a delay are we talking here that it is noticeable for you?

[Krasjet]

I got a screen recording that probably explains the situation better. Basically the DAW becomes unresponsive for around 4 seconds. The delay is definitely not normal compared to the stock plugin from REAPER.

rec2.mp4

[Krasjet]

Another observation that the problem can only be reproduced under X11. There is no delay under Wayland.

This is the Xorg version I have

$ xdpyinfo | grep version                                                                                                      
version number:    11.0
X.Org version: 21.1.11

[Krasjet]

I've pinpointed that the function that causes the freeze is XRRGetScreenInfo in pugl's src/x11.c.

https://github.com/lv2/pugl/blob/e33b2f6b0cea6d6263990aa9abe6a69fdfba5973/src/x11.c#L651

Still trying to figure out the cause though.

[Krasjet]

Some further research indicates that this might be related to NVIDIA driver.

• https://forums.developer.nvidia.com/t/xrandr-listproviders-takes-several-seconds-to-finish/214041
• https://bugs.freedesktop.org/show_bug.cgi?id=89247
  though it's weird that I could reproduce the problem on another laptop using integrated video card.

I noticed also that even the xrandr command causes a freeze, but the main cause is still the XRRGetScreenInfo function, where the minimal program that can reproduce the problem is

#include <stdio.h>
#include <X11/extensions/Xrandr.h>

int main(void)
{
  Display* dp;
  XRRScreenConfiguration *conf;

  dp = XOpenDisplay(NULL);

  conf = XRRGetScreenInfo(dp, DefaultRootWindow(dp));
  short rate = XRRConfigCurrentRate(conf);

  printf("rate: %d\n", rate);

  XRRFreeScreenConfigInfo(conf);
  XCloseDisplay(dp);
}

I'm not sure if it's really necessary to obtain the refresh rate at every window construction though. This property doesn't seem to be used a lot in pugl.

I also found another way to compute the refresh rate in GLFW. This might be the way to go to avoid the freeze https://github.com/glfw/glfw/blob/b35641f4a3c62aa86a0b3c983d163bc0fe36026d/src/x11_monitor.c#L48

[Krasjet]

This problem doesn't seem to be NVIDIA specific. Probably just the problem of X11. I checked on another Arch Linux machine with only one integrated graphics card and it still has a delay, just much less. By defining USE_XRANDR to be 0, the delay can be eliminated.

[drobilla]

The above program works properly and exits in a fraction of a millisecond for me, Manjaro on AMD.