Change Details

It is not clear what the advantage of triple buffering is for KWin. An X11 compositor is meant to swap buffers once every frame. For that triple buffering is not necessary. The functionality is not maintained, does not reliably work as displayed by the existence of an environment variable to force some behavior, pollutes our code and every compositing-related problem that might be mitigated with triple buffering should find a simpler and more fitting solution with other means. There is one caveat which is if we shall block for retrace. We set it currently according to the result of the swap profiler and in the most common case with double buffering it is set to true. But on Nvidia systems this might be actual the wrong behavior. Instead of trying to work around this ignore the issue for now and move the overall architecture to something less complex by presenting after paint how we do it in the Wayland DRM backend and with double buffering on GLX (although this is at the moment also borken because we actually present then twice).

It is not clear what the advantage of triple buffering is for KWin. An X11 compositor is meant to swap buffers once every monitor cycle. For that triple buffering is not necessary. The functionality is not maintained, does not reliably work as displayed by the existence of an environment variable to force some behavior, pollutes our code and every compositing-related problem that might be mitigated with triple buffering should find a simpler and more fitting solution with other means. There is one caveat which is if we shall block for retrace. We set it currently according to the result of the swap profiler and in the most common case with double buffering it is set to true. But on Nvidia systems this might be actual the wrong behavior. Instead of trying to work around this ignore the issue for now and move the overall architecture to something less complex by presenting after paint how we do it in the Wayland DRM backend and with double buffering on GLX (although this is at the moment also borken because we actually present then twice).

It is not clear what the advantage of triple buffering is for KWin. An X11 compositor is meant to swap buffers once every framemonitor cycle. For that triple buffering is not necessary. The functionality is not maintained, does not reliably work as displayed by the existence of an environment variable to force some behavior, pollutes our code and every compositing-related problem that might be mitigated with triple buffering should find a simpler and more fitting solution with other means. There is one caveat which is if we shall block for retrace. We set it currently according to the result of the swap profiler and in the most common case with double buffering it is set to true. But on Nvidia systems this might be actual the wrong behavior. Instead of trying to work around this ignore the issue for now and move the overall architecture to something less complex by presenting after paint how we do it in the Wayland DRM backend and with double buffering on GLX (although this is at the moment also borken because we actually present then twice).