Which one is better for time precision, KDE or gnome

Hello
My stimuli are still images of objects that must be displayed quickly (about 10ms or less).
I wanted to know your suggestion about using KDE or Gnome to get more accurate time.
specs:
ubuntu 22.04(Gnome)
Matlab 2022a
Psychtoolbox Version 3.0.19.10
AMD Radeon RX 580 Series (polaris10, LLVM 15.0.7, DRM 3.54, 6.5.0-28-lowlatency)
Monitor: 240 HZ

Thank you

Doesn’t really matter, so i’d say stick to your GNOME if you like it. If you open a bog-standard (== top-most, top-level, unoccluded, decorationless, opaque / non-transparent) Psychtoolbox fullscreen onscreen window that covers the whole X-Screen, then most desktop environments, including KDE and GNOME, will unredirect that OpenGL fullscreen window and give PTB direct low-level control over page-flipping, for lowest latency / highest performance / best timing/timestamping precision and trustworthiness.

This is especially true for gpu’s with FOSS graphics drivers (ie. everything but NVidia), and even more so for AMD gpu’s, so your AMD RX580 was a good choice for that, as was choosing a low latency Linux kernel.

If anything would be suboptimal wrt. timing on such a setup, e.g., the desktop environment failing to unredirect the PTB window thereby impairing timing somewhat, PTB would print lots of “…pageflipping hasn’t been used…” warnings with pointers to troubleshooting tips.

That said, there are some small differences:

Some versions of KDE on some setups fail to automatically unredirect fullscreen windows on a multi-display setup. In this case PTB will print all those warnings, and you can press ALT+SHIFT+F12 to manually disable compositing for the running session, or do the same permanently somewhere in the KDE display settings → Compositor settings. GNOME I haven’t seen fail to unredirect in over a decade.

I personally prefer KDE as desktop, but PTB is tested with both KDE and GNOME.

One advantage of GNOME is if you want to use windowed non-fullscreen windows or transparent windows etc.: Setting a special evironement variable allows to enable some experimental timing support that can also retain full timestamp precision and trustworthiness for simple single-window setups under typical conditions by taking advantage of some timing mechanisms in GNOME/Ubuntu’s mutter desktop compositor. PTB will tell you about that option if you open a windowed window under GNOME / Ubuntu desktop. This feature doesn’t work for more complex scenarios like async flips, multi-window, frame-sequential stereo, as the lack of funding didn’t allow me the work time to implement full support. But it does make PTB on Linux/X11 with GNOME the only existing solution for getting windowed/partially transparent windows and still trustworthy experiment visual timing under some conditions. As the compositor has significant overhead though, you would likely not be able to run that at 240 fps / Hz, whereas regular fullscreen mode should work at 240 fps on a 240 Hz monitor if your system has good timing otherwise and your script / visual stimuli are simple enough to to complete a rendering + present cycle in only (1000 msecs / 240 = ) 4.16 milliseconds. On AMD + Linux we also have all the help VRRSupport on suitable Freesync/VRR capable displayport monitors for fine-grained timing not locked to integral refresh cycles.

-mario

2 Likes