GNOME 42 Released With Many Improvements From Wayland To GTK4 Porting

[MrCooper]

[...] basic apps such as the calculator being now delivered as flatpack (with all the bloat it entails).

Sounds like you misunderstood the release notes there. Current versions of the GNOME apps being available as flatpaks does not mean they're available as flatpaks only. If you don't like flatpaks, just continue using the distro-packaged versions. In other words, this is a downstream distro choice, not an upstream GNOME one.

That's great, but what they didn't mention is that if your program is unfortunate enough to be using GTK, then as of GTK4, you are forced to opt into event compression - meaning you never actually see the low-latency benefits of this; the toolkit greedily keeps them all for itself.

Not the same thing.

What was fixed in mutter 42 is that mutter held back delivery of mouse input events until the next time it worked on an output frame. This meant that mouse input events were only sent out at the display refresh rate and could get delayed by up to one display refresh cycle (16.6... ms at 60 Hz). As a result, running mouse-controlled games at frame rates higher than the display refresh rate was mostly pointless.

Event compression in GTK just means that if multiple events have arrived by the time the application processes them, they are compressed and reported as if there was only a single event resulting in the same final state. This does not result in events getting delayed; it makes no functional difference for the vast majority of applications, and saves event processing CPU cycles for them. That's why it's the sane default. Per the text you quoted, the minority of applications which do want all individual events (e.g. painting apps) can get them via gdk_event_get_history.

[fulalas]

it's hard to get excited over: new terminal and text-editor apps, a redesigned screenshotting experience, basic apps such as the calculator being now delivered as flatpack (with all the bloat it entails).

Not only it's 2022, and screen-snippers, image viewers, terminals and text editors have been perfectly stable and useable since the nineties. [...] It feels like a lot of waste when every DE under the sun feels the need to code from scratch all the basic system utilities...

I couldn't agree more!

[ⲣⲂaggins]

Not the same thing.

What was fixed in mutter 42 is that mutter held back delivery of mouse input events until the next time it worked on an output frame. This meant that mouse input events were only sent out at the display refresh rate and could get delayed by up to one display refresh cycle (16.6... ms at 60 Hz). As a result, running mouse-controlled games at frame rates higher than the display refresh rate was mostly pointless.

Event compression in GTK just means that if multiple events have arrived by the time the application processes them, they are compressed and reported as if there was only a single event resulting in the same final state. This does not result in events getting delayed; it makes no functional difference for the vast majority of applications, and saves event processing CPU cycles for them. That's why it's the sane default. Per the text you quoted, the minority of applications which do want all individual events (e.g. painting apps) can get them via gdk_event_get_history.

I wish this were true. The documentation at https://developer-old.gnome.org/gtk4...rameclock.html says otherwise:

The clock has several phases:

• Events
• Update
• Layout
• Paint

The phases happens in this order and we will always run each phase through before going back to the start.

The Events phase is a stretch of time between each redraw where GTK processes input events from the user and other events (like e.g. network I/O). Some events, like mouse motion are compressed so that only a single mouse motion event per clock cycle needs to be handled.

The only way to compress a frame(=clock cycle)'s worth of mouse motion events involves introducing up to a frame of latency. So if this is true, it is literally impossible to write a mouse-controlled game with GTK4, should you want to.

[Mez']

It's funny how the release notes in Phoronix seem to be infinitely more interesting than the official ones.
Is it a symptom of the priorities of the developers of Gnome being completely misaligned with my own desires?

I have no skin in the DE wars (I've been running Windows as my main desktop since the 3.1 days), but it's hard to get excited over: new terminal and text-editor apps, a redesigned screenshotting experience, basic apps such as the calculator being now delivered as flatpack (with all the bloat it entails).

Not only it's 2022, and screen-snippers, image viewers, terminals and text editors have been perfectly stable and useable since the nineties. It is also that those are the kind of utilities that users might have strong opinions about and prefer using their chosen ones instead of the defaults (ex: I prefer wscite, irfanview, putty over their win native equivalents). It feels like a lot of waste when every DE under the sun feels the need to code from scratch all the basic system utilities...

Makes sense. This release doesn´t bring much added value.
Reinventing the wheel or NIMBY has been a strong Gnome trend for the last 2-3 years. With terrible results in general, and little to no adoption of reinvented apps.

In the meantime, this release doesn´t address the recurrent issues raised by Gnome users, it probably strips down a few more features (more than it adds?), the theme (though improved) is still amateur compared to what... mere amateurs manage to create.
We´ll just rely on extensions and 3rd party themes as usual to make up for Gnome´s shortcomings, this release won´t change that.
I don´t see anything in what´s avertised that will make most people´s workflow better, or even look better to the eye.
42 will pass through unnoticeably.

[yump]

Event compression in GTK just means that if multiple events have arrived by the time the application processes them, they are compressed and reported as if there was only a single event resulting in the same final state. This does not result in events getting delayed; it makes no functional difference for the vast majority of applications, and saves event processing CPU cycles for them. That's why it's the sane default. Per the text you quoted, the minority of applications which do want all individual events (e.g. painting apps) can get them via gdk_event_get_history.

That is not what the documentation says:

The history includes positions that are not delivered as separate events to the application because they occurred in the same frame as event.

I.E., the events are not undeliviered because the application ran out of CPU time to process them, but because the GTK developers decided, on behalf of the application, that it is okay to delay the response to the event until the next frame.

[finite9]

Been using Gnome since F16, and there's never really been anything else I personally liked, but sometimes I feel that the devs could spend their time better. I want more under-the-hood changes and large, sweeping revolutionary changes, and massive advances in integration-related changes, rather than "we implemented dark mode" and "theres a better screengrabber/recorder" or "we've changed font to Noto". Not that I dont want those features!! I consider them mandatory and it's about time the screengrabber was updated. But when a major release lists those two as its most prominent features, Im kind of like "was that it??".

Disclaimer: im just a user, with little insight and this is my "end-user opinion". Be kind

[MrCooper]

I wish this were true. The documentation at https://developer-old.gnome.org/gtk4...rameclock.html says otherwise:

The only way to compress a frame(=clock cycle)'s worth of mouse motion events involves introducing up to a frame of latency.

No. The Update/Layout/Paint phases are where the next application frame is constructed, based on the input events which arrived during the previous Events phase. The compressed event they get reflects all individual events which arrived during the Events phase.

So if this is true, it is literally impossible to write a mouse-controlled game with GTK4, should you want to.

Not at all. The latency will mostly depend on the timing of when the Update phase starts. The event compression makes no difference for that.

I.E., the events are not undeliviered because the application ran out of CPU time to process them, but because the GTK developers decided, on behalf of the application, that it is okay to delay the response to the event until the next frame.

See above, no events are artificially delayed. All events which arrive in time are taken into account.

[renkin]

It´s actively worked on in wayland.. IMHO gnome is not required to support HDR, wayland needs to support it, once that´s done, the application can notify wayland if it want´s it surfaces to be 10bit / apply a HDR Gamma Curve on them..
As far as i understand the current development in wayland, they want to combine Color Management and HDR and release them together, somehow makes sense, as gamma curves and translation between two colorspaces is almost the same operation, you get an input 3 channel value and generate an ouput 3 channel value via a LUT or some function.

I'm pretty sure you got that backwards. Wayland is not a display server. It's just a protocol. The actual implementation of the Wayland display server protocol is done by the Gnome and KDE devs for their respective environment. They're essentially building their own Wayland compositors according to the Wayland spec.

So no. They won't be getting functionality for free if Wayland "supports" it. They'll still have to implement it themselves.

[caligula]

It's funny how the release notes in Phoronix seem to be infinitely more interesting than the official ones.
Is it a symptom of the priorities of the developers of Gnome being completely misaligned with my own desires?

It's the same with commercial software. Just look at release notes of any Android app or Firefox. The public changelog contains few entries along the lines of "bugfixes, new featutes #1, Forum ,and #3".

Not only it's 2022, and screen-snippers, image viewers, terminals and text editors have been perfectly stable and useable since the nineties. It is also that those are the kind of utilities that users might have strong opinions about and prefer using their chosen ones instead of the defaults (ex: I prefer wscite, irfanview, putty over their win native equivalents). It feels like a lot of waste when every DE under the sun feels the need to code from scratch all the basic system utilities...

Most of the talented workforce today is developing only web applications. Vue, React, Svelte, Nextjs, Nuxt, Flutter cybernetically enhanced web apps, hydration, tree-shaking, and other interesting stuff.

Web frameworks use liberal MIT style licenses, not some stinking copyleft crap. It's also truly cross-platform. Electron and Node run on every OS and scale well. E.g. one could build an Electron. The web guys also hate statically typed and compiled languages. The only acceptable pre-processing is minification and bundling of node modules. HTTP/3 even makes bundling less useful thanks to efficient use of bandwidth. You also don't need offline apps these days. E.g. look at Ukraine or Russia. They're doing just fine with SaaS services. No problems whatsoever.

[Bilbo Baggins]

In the meantime, I've done a side-by-side comparison of text rendering in GTK3 vs GTK4 (GnomeOS March 25 nightly build) on a range of different displays, rendering a range of different typefaces and font sizes:

• 96ppi external monitor: GTK4 obtrusively blurred along the horizontal axis; GTK3 almost perfectly sharp.
• 115ppi laptop display: Blurring in GTK4 is still obvious, though not quite as in-your-face as on the 96ppi monitor.
• 165ppi laptop display: Difference between GTK4 and GTK3 is subtle, but the blurring in GTK4 is enough to cause eyestrain.

On close inspection, the blurring in GTK4 is mostly from its failure to use subpixel rendering. Glyph (letter) placement is mostly not nearly as bad as it could be.
The blurring of text in GTK4 is going to be a big usability and eye strain problem, because the overwhelming majority of laptop and desktop displays in use today (and even being sold today) are conventional LCD displays, and the overwhelming majority aren't high-dpi. If you look at what's being sold in 2022, or at what's being used, 1080p and the like are still THE standard for laptops and for desktop monitors.
Apple can get away with dropping subpixel rendering because everything they've sold since late 2019 has a high-dpi (>200ppi) "Retina" display.