napari: Very slow rendering when using `autoswap=True` in the VisPy Canvas

Looks like you went already deep down the rabbithole 😃 I think this should be brought up over at Vispy for sure. @ksofiyuk since you have a good picture of the problem, do you mind opening an issue at vispy (linking here as well)? Otherwise let me know and I can take care of it.

In the meantime, even heavy stuff with fast camera movements looks exactly the same for me with autoswap=False, so I’m in favor of doing that in napari until we figure it out on the vispy side.

looking on this wiki https://www.khronos.org/opengl/wiki/Swap_Interval it looks like selection of synchronized and non synchronized swap buffer should be possible.

I see few references to glFinish in vispy. Maybe this could be a good way to research?

Did this fix should happen in napari or in vispy?

I think it has almost nothing to do with napari as all the OpenGL stuff is happening inside VisPy. VisPy should just have another thread for OpenGL stuff.

The simplest solution is to put only SwapBuffers in a separate thread, it works at least for me and completely resolves the issue, using something like this (this code is just for illustrative purposes):

    # def __init__
        self._swap_buffers_worker = threading.Thread(target=self.swap_buffers_thread, daemon=True)
        self._swap_buffers_queue = queue.Queue()
        self._swap_buffers_worker.start()
        # ...

    def swap_buffers(self, event=None):
        self._swap_buffers_queue.put(1)

    def swap_buffers_thread(self):
        while True:
            self._swap_buffers_queue.get()
            self._backend._vispy_swap_buffers()

instead of just

    def swap_buffers(self, event=None):
        self._backend._vispy_swap_buffers()

I think it should be implemented somewhere there: https://github.com/vispy/vispy/blob/5449e3402b35da4d6a8215d8d72e19dcf05917d7/vispy/app/canvas.py#L415

which Xubuntu

I remember multiple problems on Xubuntu, and I finally switched to Gnome Shell. As I read the team who manages XFCE is very limited and they do not have enough resources to fix all problems.

It is just like here PyQt5 OpenGL swapBuffers very slow, where the issue was caused by inappropriate use of swapBuffers.

Based on the accepted response to linked StackOverflow. Could you check if #5710 solves your problem?

As @alisterburt described, the swap buffer is to avoid flickering. It is a common practice used in programming GUI applications (even many games using it).

@Czaki @alisterburt I’m pretty sure that swapBuffers is just not used in a proper way in VisPy causing performance issues on some machines. It is just like here PyQt5 OpenGL swapBuffers very slow, where the issue was caused by inappropriate use of swapBuffers.

I could blame my system if all OpenGL applications were laggy, but I don’t have problems with other 3D applications, even with other PyQt apps that use OpenGL.

thanks for reporting back @ksofiyuk !

I ran the same test as you @ksofiyuk and enabling autoswap makes no discernible difference in FPS on my system.

It does not feel like the double buffering makes a big difference during 2D/3D rendering on my system, there is a slight difference when rotating the 3D camera extremely quickly but nothing perceptible when doing things ‘reasonably’. In this context, I think it would be safe to default to autoswap=False on the canvas to solve this problem

@ksofiyuk Probably not directly related to this, but I note you have PyQt5: 5.12.3 Is there a specific reason you’re using this version, which is quite old (it’s napari min requirement)? I ask because it’s increasingly tricky to support pre 5.13 Qt while trying to improve Qt6 support.

@psobolewskiPhD I’ve just updated it all to Qt: 5.15.2 PyQt5: 5.15.9. The performance issue with autoswap=True remains exactly the same.

There is no any specific reason for PyQt5: 5.12.3. I just haven’t updated it for a long time 😄 .

@ksofiyuk yep - just asserting that the callback is indeed called and the example runs as expected on my machine on main

Ok, then it looks like it is indeed a platform specific bug.

@ksofiyuk yep - just asserting that the callback is indeed called and the example runs as expected on my machine on main

Very cool find @ksofiyuk and thanks for the ping @jni

From some Googling it seems “double buffering” is used to prevent flickering and improve the smoothness

An OpenGL canvas maintains two buffers for drawing:

The front buffer is the buffer that is currently visible on the screen. It contains the latest completed frame. The back buffer is the buffer that is not visible on the screen. It is where the application draws the next frame while the front buffer is being displayed.

“swap buffers” swaps the roles of the front and back buffers. The back buffer, which contains the newly drawn frame, becomes the front buffer and is displayed on the screen, while the previous front buffer becomes the back buffer and is now used for drawing the next frame.

It’s possible that turning this off will lead to some ‘tearing’ where partially rendered frames are visible sometimes - I don’t have any experience with this so I vote we run the experiment, get a few people on different systems to test and see what happens!