The mouse cursor is a lot slower on 2.16.2 compared to 2.15.0

[AlanGriffiths]

This has been seen by @freefos on an ARM Cortex-A55 based SOC (Rockchip RK3568B2) and might be restricted to ARM systems.

The mouse cursor is a lot slower on 123-mir2.16.2 compared to 121-mir2.15.0.

On 121-mir2.15.0 the mouse cursor moves very smooth.
On 123-mir2.16.2 the mouse cursor moves very slowly and stutters.

Original report

[Saviq]

@RAOF would you be able to look at this in your am?

[RAOF]

Hm. So on careful inspection the only thing that stands out between the two logs is the framebuffer config: 2.15 uses an RGBA 8880 config, 2.16 uses an RGBA 8888 config.

I suspect that the stuttery mouse is an artifact of a general performance difference - @freefos, is it correct that 2.16 generally performs worse?

#3206 re-adds hardware cursor support, which will likely make the cursor more responsive.

I think I need to add some extra information to our logging in order to track down what is actually happening here. We don't have enough information about how the framebuffer is being allocated to say anything more concrete.

[freefos]

@RAOF I can confirm that the general performance is worse.

[Saviq]

@freefos could you please try snap refresh ubuntu-frame --channel edge/mir-pr3206? It has the hardware accelerated cursor again.

[freefos]

@Saviq I've tested the new version.
The performance is the same and there is no cursor anymore.

There seems to be an issue with setting the cursor.
A reboot didn't help.

2024-01-29T14:11:00+01:00 ubuntu-frame.daemon[14180]: [2024-01-29 14:11:00.697377] < -warning- > gbm-kms: set_cursor: drmModeSetCursor failed (No such device or address)
2024-01-29T14:11:00+01:00 ubuntu-frame.daemon[14180]: [2024-01-29 14:11:00.705170] < -warning- > gbm-kms: move_cursor: drmModeMoveCursor failed (Bad address)

log_129-mir2.16.2+dev68.txt

[Saviq]

Thanks @freefos, @RAOF will be back on it in his tomorrow.

Can you confirm, in the mean time, how do you measure performance?

[freefos]

@Saviq
Currently just by scrolling on a webpage.
So not very scientific...

How do you guys test this?

[Saviq]

@freefos well, we monitor the results from glmark2, and CPU/memory consumption for a handful of scenarios. These didn't surface any problems with 2.16, but that may well not covering some cases, one of which you may have encountered.

[freefos]

@Saviq I did some tests with MotionMark

Here are the results:
121-mir2.15.0

129-mir2.16.2+dev68

[AlanGriffiths]

The performance is the same and there is no cursor anymore.

I tried to reproduce on RPi400. First thing I noticed was "no cursor" - and that was with Frame/stable!

I'm not sure what can have changed (obviously not Frame/Mir), but found that running in devmode got the cursor back.

[Saviq]

Huh! The most suspect thing here to me is the 15fps (that's detected, not benchmarked).

On Intel, I couldn't notice any difference, but on a Pi4 I also got the detected framerate at 15fps. The CPU usage of frame is significantly higher just looking at the main page of MotionMark on wpe-webkit-mir-kiosk.

[AlanGriffiths]

I tried to reproduce on RPi400. First thing I noticed was "no cursor" - and that was with Frame/stable!

Sorry for the noise. This happens when running Frame directly as a use (as in frame-it wpe-webkit-mir-kiosk.cog), but doesn't happen when run as a root daemon.

[update]

Filed as: canonical/ubuntu-frame#165

[AlanGriffiths]

The CPU usage of frame is significantly higher just looking at the main page of MotionMark on wpe-webkit-mir-kiosk.

Confirmed (2.15 is around 15-20% CPU, 2.16 is around 50-70%)

Can also confirm similar results from motionmark when run on RPi400

[RAOF]

There seems to be an issue with setting the cursor. A reboot didn't help.

2024-01-29T14:11:00+01:00 ubuntu-frame.daemon[14180]: [2024-01-29 14:11:00.697377] < -warning- > gbm-kms: set_cursor: drmModeSetCursor failed (No such device or address)
2024-01-29T14:11:00+01:00 ubuntu-frame.daemon[14180]: [2024-01-29 14:11:00.705170] < -warning- > gbm-kms: move_cursor: drmModeMoveCursor failed (Bad address)

Looks like there's an additional failure path the gbm-kms platform needs to address; it would appear that the rockchip DRM driver does not support the standard HW cursor API.

On Intel, I couldn't notice any difference, but on a Pi4 I also got the detected framerate at 15fps. The CPU usage of frame is significantly higher just looking at the main page of MotionMark on wpe-webkit-mir-kiosk.

Ok. My hypothesis is that the CPU copy output fallback is being taken here, but we don't have any logging of the actual display/rendering topology we select.

But the difference in detected framerate is odd. My guess is that Firefox is using the empty frame events it sends to derive a vsync signal, but that shouldn't result in any actual rendering or really touch the platform at all, so its not clear to me how that's happening.

On further thought; it's not Firefox at all; it's WebKit. I wonder how MotionMark asks for the display refresh rate, and how WebKit calculates it.

[Saviq]

On further thought; it's not Firefox at all; it's WebKit. I wonder how MotionMark asks for the display refresh rate, and how WebKit calculates it.

Yeah it's certainly something it's measuring - on its first page you can see it's changing colours, I bet it's measuring how quickly it can do that, and approximating FPS, capped at vsync. I think it's a result of the slower rendering, not a symptom / cause.