It turns out that remembering to reset the ops list helps… The performance issues were caused by the list growing ever larger, as one would expect. However, the rest of my analysis still seems to be correct: we're indeed ignoring vsync when reacting to Expose events, which does render (a lot) of unnecessary frames. It's just not as detrimental to performance as I thought.

Using the X11 backend, when receiving an Expose event, Gio immediately draws and submits a new frame, apparently ignoring vsync. On the one hand, this is desirable, because we don't want to introduce an extra frame of latency. On the other hand, this is problematic because Expose events can arrive at a rate much higher than the display's refresh rate, probably close to the mouse sampling rate, which can be as high as 1000 Hz; even my trackball samples at 500 Hz.

Redrawing and submitting frames to X11 that frequently not only causes elevated GPU usage, it also bogs down the X11 server, leading to a very laggy experience. This affects at least resizing windows, but also moving one window over another when no compositor is running.

Expose events do have a count, and Gio only redraws on the "final" one, but on my system I am mostly observing events with a count of 0, rarely with a count of 1.

The program at https://go.dev/play/p/oJIwPflqvMZ.go trivially reproduces the issue for me. Run it and notice that resizing the window feels laggy. On X11 without a compositor running, drag another window across it and notice severe lag.

The video at https://www.youtube.com/watch?v=j3h05lDbwz0 demonstrates the issue, although it is a lot more severe when not recording. (The video also demonstrates the clip area not working correctly, which is currently happening for me when shrinking the window. I'm not sure that's related to this issue, however.)

I was able to reproduce the same kind of lagginess when resizing windows on Weston, so the Wayland backend probably has the same problem (though not for expose events, since Wayland is always composited.)

I've seen some people have this issue, when using ANY locale other than en_US.

On January 30, 2024 9:17:21 PM GMT+03:00, ~dominikh outgoing@sr.ht wrote:

Is that the only output you get? What is your locale? This looks similar to https://github.com/dominikh/gotraceui/issues/148

Is that the only output you get? What is your locale? This looks similar to https://github.com/dominikh/gotraceui/issues/148

This program offsets by fractional amounts and draws two rectangles, one using clip.Rect and one by drawing our own path. The rectangle drawn with clip.Rect aligns with the pixel grid, ignoring the fractional components of the offset, while the manually drawn rectangle anti-aliases as expected.

I've sent a patch.

Would you be interested in trying to implement this change (sending key events for modifiers)?

As of 13183522dd7688edad951da9f37931ed658c1d1a we should already be sending key events for modifiers. Key sets also sort of work, but are slightly unintuitive. The key set "Ctrl|Shift" will detect when ctrl or shift are pressed in isolation, but not when both are pressed together. For that, we also need to listen for Ctrl-Shift and Shift-Ctrl.

But as discussed in private, just getting events for modifier keys isn't sufficient for widgets to be able to query for the state of a modifier. Many widgets may want to know that CapsLock is pressed, but only one of them will have the focus to know so. We discussed one possible solution, a key.InputOp that ignores the input tree and allows all registered tags to get notified of key presses. However, that's still not enough for toggles like caps-lock, as the user's code will not know the current state of the key before it gets pressed for the first time.

When scrolling vertically using a mouse wheel while on a horizontal layout.List, the list should scroll.

This is pretty similar to #398, except that one got closed because of shift+scroll, which I don't think is good enough. Compare, for example, with an overly full tab bar in Firefox. It can be scrolled horizontally just by using the scroll wheel.

(I've only been talking about mouse wheels because I have no idea how the world currently behaves for touchpads.)

The fix seems to work. Well done. I would've never guessed that to be the problem. Can I ask how you figured it out?

~dominikh let me know if the proposed fix works for you.