Poor desktop performance on large monitors

[byzantic]

First of all, congrats on the enormous amount of work that you have done! But (you guessed..) .. I’m having a few issues on Bookworm / Pi 5 that seem to be related to large monitors (4K) and/or the video driver.

1. the mouse is a bit laggy even when turned up to max. This true for Pi 5 and Bookworm on a Pi 400
2. It’s difficult to set up a reasonable set of display defaults. The large screen default is OK, but applications (e.g. Chromium) tend to use a smaller font for the menu bar.
3. Apps like Chromium can be set to ‘zoom’ to 175%, but this does not affect the menu bar, as noted above.
4. The mouse is very laggy when inside some apps. The worst offender here is Visual Code, but Chromium is also affected. Following tips on the web, I turned off hardware acceleration on these apps, and this improves things a lot, but is still noticeably laggy.
5. With the large-screen defaults for the main display, a remote VNC session then becomes unusable. Any chance of different settings for VNC?

[theofficialgman]

2. It’s difficult to set up a reasonable set of display defaults. The large screen default is OK, but applications (e.g. Chromium) tend to use a smaller font for the menu bar.

not sure by what you mean by "large screen default" but piOS provides a command line tool wlr-randr to modify screen output options on the wayfire wayland session. these options include setting a "scale" parameter which is what you are interested in. it scales everything without hampering visual quality. Scaling to non-integer values is allowed but results in the topbar disappearing (that is probably its own bug) so I would only suggest integer scaling values for now.

[qrp73]

if your display has large resolution like 1920x1080, you can try to setup lower resolution, for example 1280x720

[byzantic]

I have been playing around with this for a few days, and I think the mouse problem is just one of physics .. . My monitor is 3840 x 2160 / 30 Hz. So, not only is the graphics field very large, the refresh rate is not that high. So a mouse movement will inevitably look somewhat 'jerky' compared to a higher refresh rate.

In fact, Ubuntu 23.04 behaves similarly. I hadn't noticed before, because previously I had been using an HDMI port on my Ubuntu box that did not support the higher frame size; when I changed over to display port, I noticed the problem.

I think there are a few ways to address the issue of appropriate font sizes.

1. Juggle around with the system font size settings, and individual app 'zoom' and font settings. This is unsatisfactory though, particularly for app title bars, which don't seem to be able to be changed.
2. Use the Wayland scaling options. This wasn't entirely successful, though; see below for some comments.
3. Set a different monitor mode - say 1920 x 1080 / 60Hz. This is probably the simplest option.

Option (2) seems interesting, but again, there were problems in practice. You can set a scale factor on the command line by using:

> wlr-randr --output <name of output> --scale 2

But what is the name of the output? It took me a while to discover that you can get details of current outputs and mode settings using wlr-randr without arguments, discover the name (usually HDMI-A-1) and hey presto. For permanent use, it's better to put this in the /home/pi/.config/wayfire.ini file.

However, this still doesn't quite do the job. The attraction of using a scaling factor is that the rendering should be done at the higher pixel resolution by the graphics driver, even though the app is working in scaled co-ordinates. As explained above, I have to turn off 'hardware graphics acceleration' for various apps such as VS Code; now the rendering is done only in scaled co-ordinates and the fonts are no longer properly antialiased - in fact they are worse than if a lower screen resolution is used.

I think this is a fundamental issue with high resolutions, even if I had a higher refresh monitor. Since the Pi implementation is moving towards s/w only video drivers (i.e. not using the video core firmware), it will always be necessary to turn off h/w acceleration for graphics.

In a way, though, this is a testament to the Pi 5's power. Previously, I had never considered the possibility of using the Pi as a daily driver, but the compute performance of the Pi is more than adequate for my needs. It's just that the graphics is not geared up for workstation performance - but this is unsurprising, since it costs less than a low-end graphics card!

I'll leave this open for more comments for a while, but I think its not a real issue.

[timg236]

I think this is a fundamental issue with high resolutions, even if I had a higher refresh monitor. Since the Pi implementation is moving towards s/w only video drivers (i.e. not using the video core firmware), it will always be necessary to turn off h/w acceleration for graphics.

That's incorrect. The display hardware acceleration (HVS - hardware video scaler) and GL (V3D) are both Linux drivers with direct hardware access. Avoiding roundtrips to VideoCore firmware avoids latency and improves vsync handling.

[byzantic]

I stand corrected. However, it's certainly true that turning off h/w acceleration in VS Code improves mouse behaviour when the mouse is over the code window.

[timg236]

It sounds like the increased V3D workload from using GPU acceleration in VSCode is causing mouse updates in Wayland (probably) or maybe KMS to be stalled waiting for other GL jobs to complete. Ideally, mouse-cursor updates should always be immediate because these are handled by the display HVS rather than GL but that is possibly quite an involved update to the composition stack,