GNOME 3.30 Ready For Release Today With Many New Features & Improvements

[cl333r]

You should wonder why you bought Nvidia in the first place.. I'm about to go Ryzen + AMD APU (Dell Inspiron) for my next laptop, wish me luck

You should wonder why you're not vegan in the first place.. I'm vegan for 150 years + do yoga (Tai Chi) with my family, so become a vegan fag if you wanna be healthy.

[buzzrobot]

On your 1080Ti, how smooth is dragging windows around in Gnome Shell? (either Xorg or Wayland).

Seems smooth enough on Xorg. Haven't used Gnome on Wayland enough to have an opinion there.

[lem79]

Seemssmooth enough on Xorg. Haven't used Gnome on Wayland enough to have an opinion there.

That's interesting. I'm assuming window movement is as smooth as just moving the mouse around then? That's not what happens here. Gnome Shell on Xorg (RadeonSI, Mesa 18.3, but has been like this as long as I can remember), the mouse is silky smooth and clearly moving at 144Hz, but windows don't as there being dragged. Worse in a Wayland session. The nVidia driver might be different then..

[Vistaus]

Colour me naïve, but I'm surprised at how much easier the move to GitLab has made understanding and appreciating the engineering mindset behind the ongoing efforts to improve GNOME (and GNOME Shell in particular).

It seems to me that the move to GitLab has been quite the win for everyone who's interested in GNOME, given how easy it is to track e.g. merge requests like you did and have them be presented within a decent looking Web UI.

I agree. The only thing I don't like though is that proposing merge requests requires more effort than on GitHub, where you can simply fork a repo and then with a few clicks propose the request. But other than that, I like GitLab and I think it was a good move.

[Vistaus]

Been using i3 for the last nine days, 15 hours and 25 minutes just out of curiosity. I'm a regular GNOME user though and I already recieved some of these updates on Debian Sid so I will check it out whenever I have some time. Mostly I just wish the Wayland session (including xwayland) will respect the monitor refresh rate. Looking at those bug reports, it looks like it might be fixed but I'm not sure. Anyone know for sure? Will I still have to use that environment variable to work around the issue?

But isn't that a Wayland issue in general? 'Cause I'm pretty sure that i.e. Sway also suffers from the cap.

[Brisse]

But isn't that a Wayland issue in general? 'Cause I'm pretty sure that i.e. Sway also suffers from the cap.

I have not yet tried Sway myself, but after reading your comment I took a look at https://github.com/swaywm/sway/issues and a quick search for "refresh rate" gave a few hits. Looks like a different issue than GNOME though. Sway was forked from i3 which relies on xrandr to change refresh rate but since Sway runs on Wayland that doesn't work and they will have to come up with a different way to change refresh rate I think.

GNOME on the other hand allows you to change refresh rate as usual but there are issues in the compositor that means it won't put out frames at the same pace as your monitor is running at. It defaults to 60fps but can be changed manually through an environment variable, but it still doesn't respect your monitors exact refresh rate and I think it only takes integers and not floating point numbers which can be a problem if your monitor is running at say 59.94hz or 119.88hz which is pretty common.

[MrCooper]

That's interesting. I'm assuming window movement is as smooth as just moving the mouse around then? That's not what happens here. Gnome Shell on Xorg (RadeonSI, Mesa 18.3, but has been like this as long as I can remember), the mouse is silky smooth and clearly moving at 144Hz, but windows don't as there being dragged. Worse in a Wayland session.

FWIW, while it's at least theoretically possible for a Wayland compositor to move both the cursor and windows smoothly and in sync, this will never be possible with Xorg, because Xorg moves the cursor directly and asynchronously, without synchronizing to window moves or any other drawing.

[lem79]

FWIW, while it's at least theoretically possible for a Wayland compositor to move both the cursor and windows smoothly and in sync, this will never be possible with Xorg, because Xorg moves the cursor directly and asynchronously, without synchronizing to window moves or any other drawing.

Oh yes, I was aware of the mouse and window movement being asynchronous. With high refresh rate screens, the hardware pointer can be seen moving at the screen's refresh rate, and very smooth in the case of 144Hz screens. That's the first clue that Gnome Shell isn't working at the refresh rate of the screen, the pointer is smooth, but dragging windows isn't. I don't know about Wayland compositors, only ever tried Shell on Wayland, and it seems to be a bit worse than on Xorg. Still, neither are usable for me just yet. Perhaps after this performance work is done, it will be.

[lem79]

For what it's worth, I tried loading up Linux Mint 19 Cinnamon the other day.. buttery smooth (Vega 56, open drivers, 144Hz 1440p), just like Unity and KDE. Gnome-Shell isn't there yet .. or it *was* there (Cinnamon is an early fork of Shell, no?), then it broke. From memory, the Budgie desktop was also super smooth at one point, now it's stuttery like Shell is (I suppose because it uses Shell as well?). That's just desktop performance. OpenGL apps and games seem fine in Shell on Xorg.

[andre30correia]

gaming with radeonSI with apu his good?, i'm looking for a new laptop but what i see about ryzen 7 2700u is not good at least at windows side