Feature: Improve budgie menu responsitivity on throttled/slower hardware

[MatthewScholefield]

Background

Whenever I open the menu and do a search, there's around a 0.2-0.3 second delay per character typed, in particular when typing the first few letters of the search. This only is noticeable when my computer is below 40% or so battery and cpu throttling kicks in.

This is of course expected behavior as it probably takes a little bit of time to search all the applications and update the view. However, this really makes the system feel laggy and could be avoided by one of the two solutions listed below.

Possible Solutions

To speed up budgie menu, two solutions could be employed, depending on what's the bottleneck:

• If rendering long lists in GTK is the bottleneck: Only render the first N search results within 0.3 seconds of a keypress where N is the number that fits on the menu
• If searching desktop entries is the bottleneck: If a search query is already running, don't interrupt it until it's finished so that some intermediate queries can be skipped (preventing input events from queuing up and causing lag)

Budgie version

10.5

Operating system

Latest Solus

Steps to reproduce the issue

Open menu on throttled cpu and type a few characters

Note

While Alt+F2 does initially lag considerably, there's virtually no input / search render lag there.

[JoshStrobl]

Both of these implementation ideas have the negative effect that perceived performance is worse if we're only partially rendering a list. Looking through the list itself isn't computationally intensive, it's likely how GTK queues and performs draws when we're toggling the visibility state of buttons.

That isn't to say there aren't places where we can improve performance, I certainly plan on doing that around the GMenu Tree usage and menu rebuilds, but search will probably need a different solution.

[MatthewScholefield]

That makes sense (GTK queueing/drawing being the bottleneck), but I don't follow how partially rendering a list would make perceived performance worse. Do you mean after the 0.3 seconds when it redraws the full list it might stutter? I could definitely imagine that doing this might introduce some weirdness around the second rendering which might end up being bad.

Either way, unless other people notice the same thing, it might be a niche issue.

[JoshStrobl]

Do you mean after the 0.3 seconds when it redraws the full list it might stutter?

I mean we'd have basically no way of knowing the system is having issues with immediately drawing the whole list specifically, so we'd have to artificially limit the initial toggled items then defer the rest until later, which may make it look like the computer was having issues with rendering the whole list when in reality, it may very well have no issues at all and we're deferring for no reason.

By the way, I totally get that this isn't ideal. I've noticed it when I downclock my laptop when it's on battery to extend its battery life. I'm just trying to think of the best ways to solve these issues and highlighting that the proposed ones aren't optimal either :)

[MatthewScholefield]

The idea is that you wouldn't notice the redraw because you can only see N items in the search list anyways. But I'm assuming the redraw might be noticeable.

Thinking about another idea, is there some hook or something in GTK when the elements have rendered on screen? (Like in React there's a componentDidMount event) If so, that would allow preventing re-renders in the middle of a render.

[JoshStrobl]

There are events called when something is shown (show), hidden (hide), as well as map / unmap events (which may be what we're looking for. But I don't believe Gtk is going to attempt to re-draw a widget when the state of it hasn't changed unless explicitly queued.