Program spends several seconds in eglSwapBuffers

I have a problem where for some reason the program now spends multiple seconds at the second eglSwapBuffers call during program startup. Appearently it waits inside the wl_display_poll method inside wayland:

#0  0x0000007f8a4d0ffc in __GI___poll (fds=fds@entry=0x7f698fde98, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/generic/poll.c:38
#1  0x0000007f8c214728 in wl_display_poll (events=events@entry=1, display=<optimized out>)
    at /home/jenkins-slave/workspace/5c078a9b05b7cdd0f6fef4d97b1d63c0/work/system/ext-wayland/src/1/workspace/wayland-1.14.0/src/wayland-client.c:1593
#2  0x0000007f8c2159ec in wl_display_dispatch_queue (display=0x22509e10, queue=0x225c3b30)
    at /home/jenkins-slave/workspace/5c078a9b05b7cdd0f6fef4d97b1d63c0/work/system/ext-wayland/src/1/workspace/wayland-1.14.0/src/wayland-client.c:1666

I thought I could solve the problem with eglSwapInterval(<…>,0), but it is already used.
What can the problem be?

Edit: How can I Post a long log here?

Btw, does eglSwapInterval have to be called separately for every surface x context combination?

Hi desperado,

If you’re working with several surfaces, make sure you’re calling makeCurrent prior to the eglSwapBuffers call and that you do this for all surfaces. Also and since I don’t know what platform are you working with, make sure the surfaces you’re working with are double buffered since that’s the purpose of eglSwapBuffers.

eglSwapInterval applies to the draw surface bound to the context that is current. If you’re using more than one surface, you will need to call eglSwapInterval for each surface making sure you previously make current the surface.

You can simply post the log as part of the message.

Please let me know if you continue experiencing any issues,

Regards,
Alejandro

1 Like

Thanks for the answer. But I only have to call glSwapInterval once for every surface regardless of future eglMakeCurrent calls, right?

Yes, you should proceed that way.

Also, and as a test in case it’s not too time consuming for you, you can try avoiding any shader being compiled during your entire program exection. Just drawing an empty scene with a clear color. If at that point you do not experience this delay during the program startup, it might be related with drivers doing last-second work / optimizations.

Best regards,
Alejandro