Firefox 75 Released With Flatpak Support, Wayland Improvements

[Mez']

that's my hands. as in "unlike you i can use my hands". workflow is something entirely different.
that's your fault, not gnome's

I disagree on all points.

A well designed DE should be able to adapt to several workflows. And what it should not do is impose a unique way to its users. It's a narrow-minded view.
But it confirms what I was saying, Gnome and people like you have their head so far buried in the sand that you forgot users pull the design, and not the other way around, i.e. the design is pushed onto them.

I can use my hands. Are you a dimwit or what? But I don't see the point on a media oriented system managed from my couch where I mostly browse, play videos, music or sometimes have a go at a game. It's not relevant and even cumbersome to use a keyboard in these cases, except to input a couple of stuff. But it certainly doesn't require one hand ready to use the keyboard. Again, you're probably too closed-minded to even think of workflows different than yours.

That said, even on my laptop, where I'm actually more traditionally seated with both hands close, I still go faster with dash-to-dock than with the super key to switch or open windows while keeping a clean desktop. Minimizing with a click on an already targeted dash icon and maximizing another window through a light scroll on a nearby icon is faster than finding the minimize button on the window, then go for the super key, spot the wanted window (randomly positioned) and go for the click to open it. I've just tried in different ways and it is a bit faster. And I don't need my left hand to be ready as if I was playing a mouse hammer game.
Plus, and that's a requirement for me, I know at all times with a visual dot (or highlight of any kind) which apps are open and how many instances.

I'm happy this design works for you, your workflow and the necessity of both your hands at all times, and that's why I'm always an advocate of options. I like people to have the choice, and not to make these choices for them (often against them). But you'll have to accept it is slower and less practical for me in many ways. And I certainly don't see why I would slow down my workflow to accommodate (be forced down) to a design thought by somebody else. As I mentioned in a different article comment, I'm a Business Analyst, I have to prevent people like you to force down stuff on actual operational end users every single day.

So yes, it's Gnome's fault to narrow down the possibilities for users so much. I'm not asking to have options for every different workflow (or being KDE), but at least to have a limited set of options to accommodate the most common use cases and not just the one.

[MrCooper]

I checked and you are correct. I'm confused because I do get input lag on heavy CPU/IO, and I'm not sure where it comes from. This is in contrast to X11, btw.

Xorg can appear more responsive because it has a dedicated input thread, which basically does nothing but reading input events from the kernel, queuing them for the main thread and updating the HW cursor position correspondingly. So the HW cursor keeps moving more or less immediately even while the main thread is blocked.

In contrast, Wayland compositors tend to only update the HW cursor position once for each frame they produce, consistent with the rest of the frame (so e.g. the cursor and a window being moved are always in sync, whereas with Xorg the cursor tends to be ahead of the window).

Xorg -DOES- sync output on input. On xorg output will always be -exactly- one frame after input. Higher framerate specifically means lower input lag. Xorg does it right.

Per above, while you clearly prefer Xorg's behaviour, it's pretty much for the opposite reason than you think.

Wayland doesn't do it -at all- and -can't- do it...

Pretty much the opposite: Wayland compositors could do the same thing Xorg is doing; as often when "Wayland" is accused of something like this, the Wayland protocol itself doesn't require this specific behaviour. Conversely, what Wayland compositors are doing isn't possible with Xorg (neither X compositors nor Xorg (drivers) themselves have both the knowledge and means for it).

[down1]

For me the apparent cursor lag is most noticeable when I load skype. Why skype I don't know.

[duby229]

Xorg can appear more responsive because it has a dedicated input thread, which basically does nothing but reading input events from the kernel, queuing them for the main thread and updating the HW cursor position correspondingly. So the HW cursor keeps moving more or less immediately even while the main thread is blocked.

In contrast, Wayland compositors tend to only update the HW cursor position once for each frame they produce, consistent with the rest of the frame (so e.g. the cursor and a window being moved are always in sync, whereas with Xorg the cursor tends to be ahead of the window).

Per above, while you clearly prefer Xorg's behaviour, it's pretty much for the opposite reason than you think.

Pretty much the opposite: Wayland compositors could do the same thing Xorg is doing; as often when "Wayland" is accused of something like this, the Wayland protocol itself doesn't require this specific behaviour. Conversely, what Wayland compositors are doing isn't possible with Xorg (neither X compositors nor Xorg (drivers) themselves have both the knowledge and means for it).

I can certainly accept this argument.

However that doesn't mean I agree with you. As is, no wayland compositor is suited for desktop usage of any kind and especially not so for gaming , it's just too unbearable because of input lag. While you think it's a good thing that the only thing wayland is capable of is input lag and a bad thing that xorg isn't capable of it. I think that xorg being incapable of input lag is good and wayland only being capable of input lag is a very bad thing.