menu_view: support multiple dialogs

[nfeske]

Up until now, multi-window applications like Sculpt's Leitzentrale require one menu-view component per dialog. Sculpt requires 9 components on that account. By extending menu_view with the ability to present multiple dialogs, those components can be merged into one, reducing the boot time, and keeping the runtime subsystem tight when adding further dialogs down the road.

[nfeske]

Fixed by the commit https://github.com/genodelabs/genode/commit/9deed8cb62eaa16e9115800a87cb577975945c0c.

Note that users of the menu-view component must adjust the menu_view configuration, declaring a dialog. To attain the previous behavior, it should state:

<config>
  ...
  <dialog name="dialog"/>
</config>

The related commit https://github.com/genodelabs/genode/commit/b5b1ecae728af442406362f54a15ac44d70674e5 improves the robustness when switching fonts on the fly.

Commit https://github.com/genodelabs/genode/commit/191e28126613c2afe39f922d77d076e7c9f8e073 updates the dialog library to use multi-dialog feature of menu view.

Commit https://github.com/genodelabs/genode/commit/411efb67de7135a3281efd773950bc3d08295a01 updates Sculpt to benefit from the change.

[mewmew]

Not sure if this is the best place to report it, but I've noticed a performance regression between Sculpt 23.10 and 24.04 (on the staging branch, latest commit 381f37ab15942cf9cb20e946aa503f4fea8e3f60. Note: I've not bisected to find the responsible commit), with regards to mouse over actions on the dialogue menus in Leitzentrale.

Using Sculpt 23.10 on old hardware (in my case x220), the dialogues of Leitzentrale were very performant.

When updating to Sculpt 24.04, it seems that the rendering performance of dialogues is somehow effected. The best way to test this on x220 is to move the mouse over a dialogue item (such as opening the "usb" menu dialogue that shows partitions on the USB drive) and moving the mouse over this dialogue item. When the mouse cursor is moved on the background image it is very rapid and responsive. However, as soon as the mouse cursor is moved above the dialogue item, it slows down and becomes a bit laggy (not showing all frames). And as soon as the mouse cursor gets outside of the dialogue item, it speeds up again to its original speed and feels rapid again.

I've noticed the same "slow down" when moving the mouse cursor over any text box, such as those used when clicking Files -> config -> README -> Edit, and moving the mouse cursor over the presented readme.

Note, the mouse cursor is also experiencing a slow down when moved above the file system view presented when clicking FIles -> config, and moving the mouse cursor above the file tree list.

Just wanted to add this commit to see if anyone else has experienced a similar rendering speed regression when using older hardware?

Cheers, Robin

Edit: I think the slowdown in performance is even more visible when changing font size from medium to either small or large. At least with large font size the slowdown feels even more noticeable. Perhaps that's just my imagination, but wanted to write it down anyways for trouble-shooting.

[nfeske]

Thank you @mewmew for superb testing! Your comment prompted me to dust off an old x201 where I could reproduce the lagging mouse pointer. The problem is actually not related to the menu_view change of this issue but caused by the priority scheme we recently tweaked for the improved audio timing. Can you give commit https://github.com/genodelabs/genode/commit/6a2abc11e0561834ddf22c843deb726404698310 a try? Subjectively, this commit restores my x201 to run as smoothly as with Sculpt 23.10 for me.

[mewmew]

Can you give commit https://github.com/genodelabs/genode/commit/6a2abc11e0561834ddf22c843deb726404698310 a try? Subjectively, this commit restores my x201 to run as smoothly as with Sculpt 23.10 for me.

I can confirm that the performance regressions have been fixed with this commit.

Really incredible how quick you were to track it down @nfeske! Wonderful to have a speedy Sculpt on x220 once more : )

[nfeske]

More than happy about your confirmation, @mewmew.

[mewmew]

More than happy about your confirmation, @mewmew.

I did some further testing when having other scenarios running.

When running an audio playback example (using the sdl2_playmus app on rev b9bd93847baa1d25416138c8dd93b09440583a18 and genodelabs/genode-world@8a5e47aac5caf8751bea3ea3d65fbdb991657f98 on x220), it seems like the mouse movement now makes the playback speed of the music slow down (when moving the mouse a lot), and then speed up again when not moving the mouse.

So it seems the issue of finding the perfect balance with scheduling is more delicate and may need some further fine-tuning.

[nfeske]

So it seems the issue of finding the perfect balance with scheduling is more delicate and may need some further fine-tuning.

That is definitely so, and quite expected. It will be a matter of practically using and refining the new version with a variety of applications over the course of the next few months.