GTK4 Gets Smoother GPU-Accelerated Scrolling, Modern Cursor Blinking

[Guest]

Failing to take account a broader ordinary users without setting a human interface guideline or a standard is worse when it comes to a desktop environment aiming at a large audience. Tech savvy means advanced power users capable of customizing their desktop using extensions as found on Gnome Shell. Gnome Classic found on Red Hat Enterprise 7 and up along CentOS 7 is one of examples . Endless OS does similar stuff as well using Gnome Shell as a foundation.
Applications must adhere to a core standard like handling touch or stylus functions as example or facing irrelevance when their competitors do better and beyond.


That is your choice and you will need to respect others' choice including vendors using "that mistake of a desktop" by understand the paradigm.

I don't think your average user is the real target for the GNU/Linux desktop. I think the barrier to entry should be willing to read a pile of manuals, and knowing your way around. There are options for mouth breathers out there, and they can stick with windows for all I care.

Trying to make things easier makes them much harder, especially because people will try to avoid looking up things in available documentation, because they assume they should be able to figure out whatever it is they need.

[cynical]

JavaScript is not being used to do any significant amount of work in Gnome, so blaming it for performance issues is bizarre. It's there for ease of use and layout reasons. No one says QML is garbage, and yet what does that run on? Oh right. JavaScript. And it can do fluid rendering of 60fps animations. Do you get why? JavaScript is not being used for the rendering, it's being used for describing what the UI should look like.

[GrayShade]

JavaScript is not being used to do any significant amount of work in Gnome, so blaming it for performance issues is bizarre. It's there for ease of use and layout reasons.

This seems to be a bit of a meme. It brings quite a lot of complexity in its interactions between JavaScript and C code. And even if it might not be used in rendering, the shell uses an awful amount of CPU, part of that because the hover handlers are written in JavaScript: https://gitlab.gnome.org/GNOME/gnome..._requests/276/, https://gitlab.gnome.org/GNOME/mutter/issues/283.

When profiling cursor movement (mutter#283) with fixes applied to specifically optimize cursor movement, trigger_gc_if_needed started appearing as one of the main remaining users of CPU. Just with cursor movement.

trigger_gc_if_needed would typically occupy 20%-80% of gnome-shell's CPU usage according to Google Profiler. And according to sysprof the function js::GCRuntime::collect would typically account for 98% or more of the JavaScript profile (which obviously makes finding other bottlenecks more difficult).

Super+A spring animation spends 30-60% of its CPU time doing JS garbage collection

That's not to mention issues like spamming the journal with thousands of messages about using objects that have already been finalized, and how a crashing extension brings down your entire desktop (on Wayland). I thought we use JS to avoid that kind of thing. If it's really only used for layout, move the extensions to another process and use IPC. But no, they need to be called every time you move your mouse cursor and who knows when else, so that would be too slow. And surely it must be doing something very important, otherwise someone would just slap a try-catch around the JS code. Your panel might disappear for a couple of frames, but you wouldn't lose your work.

[cynical]

This seems to be a bit of a meme. It brings quite a lot of complexity in its interactions between JavaScript and C code.

Yeah you're right, it is a meme. If you go back and re-read that post, JavaScript is doing everything just fine. If they could rely solely on the JavaScript GC, they would be having zero issues because it would clean everything up on its own. The problems they are experiencing there are due to their implementation, where they decided to couple their GObjects to JS objects. As it says in that post, the JS GC has no idea about the C Objects, it does not know the relationship between them (because it's the JS GC, and C does not have a GC). Even in your own post you say it clearly. It's not JS that brings the complexity, it is the interaction of JS with their C code. This is something they should have thought about when they were doing the design.

Either way, what does that have to do with JS performance? Absolutely nothing! This is an oversight on their part that they are correcting, but it only leads to higher memory usage than strictly necessary.

And even if it might not be used in rendering, the shell uses an awful amount of CPU, part of that because the hover handlers are written in JavaScript: https://gitlab.gnome.org/GNOME/gnome..._requests/276/, https://gitlab.gnome.org/GNOME/mutter/issues/283.

Nope, completely wrong. Read those again. You have to have handlers when you are talking about a GUI. It does not matter if they are written in JavaScript, C, Python, Lua, or whatever. You need to be able to respond to events the occur such as a user typing on a keyboard, moving their mouse, etc. What Daniel is doing in those patches is being more specific. By adding a distinction between mouse motion events (which obviously happen a lot relative to, say, clicking) and everything else, you can allow handlers which don't care about mouse motion to not track it, which means less cpu usage. Again, nothing to do with JS at all, other than the fact that they happened to implement their handlers using JS instead of <insert your favorite language here>.

Super+A spring animation spends 30-60% of its CPU time doing JS garbage collection

And did you read why that happens? It's due to this commit. I'll quote it:

object: Queue a forced GC when toggling down

During a GC, the collector asks each object which other
objects that it wants to hold on to so if there's an entire
section of the heap graph that's not connected to anything
else, and not reachable from the root set, then it can be
trashed all at once.

GObjects, however, don't work like that, there's only a
reference count but no notion of who owns the reference so,
a JS object that's proxying a GObject is unconditionally held
alive as long as the GObject has >1 references.

Since we cannot know how many more wrapped GObjects are going
be marked for garbage collection after the owner is destroyed,
always queue a garbage collection when a toggle reference goes
down.

Again, they are queuing unnecessary garbage collections because of their terrible design decision. It has nothing to do with "JS performance sucks, wah". Obviously if you force a ton of GCs you will get bad performance. And in plain JavaScript, this is completely unnecessary since cleanup happens automatically when your object has no references.

That's not to mention issues like spamming the journal with thousands of messages about using objects that have already been finalized, and how a crashing extension brings down your entire desktop (on Wayland). I thought we use JS to avoid that kind of thing. If it's really only used for layout, move the extensions to another process and use IPC. But no, they need to be called every time you move your mouse cursor and who knows when else, so that would be too slow. And surely it must be doing something very important, otherwise someone would just slap a try-catch around the JS code. Your panel might disappear for a couple of frames, but you wouldn't lose your work.

Again, nothing to do with JS, everything to do with their implementation. Did they have to put everything on the same process? Nope. Of course, in normal JS you can modify things live and have no issues, but you need to be smart in how you create your architecture. You can't shove everything together and expect no problems.

Mutter and Gnome Shell do not need to be in the same process, that was their mistake. No, it would not be "too slow" to put them in separate processes. I don't know why they thought it was a good idea before, you would need to ask them.

The fact that it is used for event handling is part of the whole layout thing. It would not help performance to have event handling code in C. Remember, you don't lose your work if you are using Xorg. You can do a simple reload and everything is fine, and yet you are still using JS. (which btw is what makes extensions with this flexibility possible. You could not have them in C)

[GrayShade]

If you go back and re-read that post, JavaScript is doing everything just fine. If they could rely solely on the JavaScript GC, they would be having zero issues because it would clean everything up on its own.

Unfortunately, they can't use JS for everything because it's slow once it gets in the rendering path. That's what you meant, right? Or do you really think you can write a laptop-friendly UI and compositor using only JS?

The problems they are experiencing there are due to their implementation, where they decided to couple their GObjects to JS objects. As it says in that post, the JS GC has no idea about the C Objects, it does not know the relationship between them (because it's the JS GC, and C does not have a GC). Even in your own post you say it clearly. It's not JS that brings the complexity, it is the interaction of JS with their C code. This is something they should have thought about when they were doing the design.

I fail to see the difference. They have two garbage collectors (the GObject reference counting and the JavaScript tracing GC ). Having multiple GCs in the same app tends to lead to bad interactions. There are three solutions, right?

1. write it all in C
2. write it all in JS
3. deal with it and accept the weird issues caused by the GC

They chose 3. I think 1 would have worked. Are you arguing for 2?

Either way, what does that have to do with JS performance? Absolutely nothing! This is an oversight on their part that they are correcting, but it only leads to higher memory usage than strictly necessary.

Higher memory and higher CPU usage, as you say below.

Again, nothing to do with JS at all, other than the fact that they happened to implement their handlers using JS instead of <insert your favorite language here>.

Again, they are queuing unnecessary garbage collections because of their terrible design decision. It has nothing to do with "JS performance sucks, wah". Obviously if you force a ton of GCs you will get bad performance. And in plain JavaScript, this is completely unnecessary since cleanup happens automatically when your object has no references.

They trigger GCs to fix the leaks. Sounds like they painted themselves into a corner. Would they have these issues if they didn't use a garbage-collected language?

Again, nothing to do with JS, everything to do with their implementation. Did they have to put everything on the same process? Nope. Of course, in normal JS you can modify things live and have no issues, but you need to be smart in how you create your architecture. You can't shove everything together and expect no problems.

From https://wiki.gnome.org/Initiatives/W...l/GnomeShell4:

This, however, means we'd have the ability limit what extensions can do in the compositor process (for stability reasons), and reconsider whether monkey patching or well defined extension points is the way forward. It would probably be a good idea to be wary about introducing extensions in a garbage collected language in the compositor process however, but only allowing compiled compositor side extensions might be very problematic.

Straight from the horse's mouth. They coupled the extensions too tightly with the compositor. If you consider the compositor to be critical (both for performance and reliability), perhaps you shouldn't allow extensions to replace parts of its functionality.

I said nothing against calendar applet extensions written in JavaScript. What I said is that Gnome performs poorly because it uses too much JavaScript. So what exactly are you trying to prove, that it could have been faster if the JS code wasn't used for such important things? How is that different from saying that it's slow because it's using JavaScript?

Mutter and Gnome Shell do not need to be in the same process, that was their mistake. No, it would not be "too slow" to put them in separate processes. I don't know why they thought it was a good idea before, you would need to ask them.

Because they didn't care:

GNOME Shell 3 was designed to be an X11 compositing manager, meaning relied on X11 for a lot of heavy lifting, such as interacting with GPUs and input devices. With this in mind, it has not been crucial to allow low latency input handling and drawing, as when low latency and high performance throughput has mattered, the X server has been the one responsible. For example, input goes directly from the X server to the X clients, and when high performance is really important (e.g. fullscreen games), applications have had the ability to bypass GNOME Shell and rely entirely on the X server for passing along content from the client to the GPU. For visual feedback that also relies on low latency, the X server has also been completely responsible, namely pointer cursor movement.

Remember, you don't lose your work if you are using Xorg. You can do a simple reload and everything is fine, and yet you are still using JS. (which btw is what makes extensions with this flexibility possible. You could not have them in C)

That's bollocks. If I am using Xorg, I can reload TWM, written in C some 30 years ago, without losing my work. Is Gnome Shell more reliable because it's using JS? No. Is it more flexible? Maybe, but that's only because they're letting extensions monkey-patch parts of the shell instead of providing decent extension points. And we've already seen what effect it has on performance.

[cynical]

Unfortunately, they can't use JS for everything because it's slow once it gets in the rendering path. That's what you meant, right? Or do you really think you can write a laptop-friendly UI and compositor using only JS?

Why would you want to? You can write the compositor in C and then the parts that don't need C-like performance in JavaScript.

What I meant is that their problems have to do with their architecture, and not to any inherent performance problems in JavaScript. JavaScript is not slow. It is not as fast as C, but they are two completely different languages trying to do completely different things. What you lose in speed by leaving C you gain in terms of productivity, expressiveness, flexibility, runtime dynamism, memory safety, and ease of onboarding.

Everyone who keeps memeing Gnome sucks because it uses JavaScript is making the implication that if they used a different language, their performance (or memory usage) would be better. If the replacement language had the same runtime behavior and a GC (which are the pros to using JS), and they used the same architecture, then they would have exactly the same problems.

]

I fail to see the difference. They have two garbage collectors (the GObject reference counting and the JavaScript tracing GC ). Having multiple GCs in the same app tends to lead to bad interactions. There are three solutions, right?

1. write it all in C
2. write it all in JS
3. deal with it and accept the weird issues caused by the GC

They chose 3. I think 1 would have worked. Are you arguing for 2?

No, they do not have "multiple GCs in the same app". They have two separate, independent methods of memory management which they are coupling together. In fact their issue is not even a memory leak, because the objects do get cleaned up eventually, it's just that they can take longer than you would expect because JavaScript cannot track C Objects.

You are writing as if they made a conscious decision to have excessive memory usage, but they did not. This problem is something they failed to anticipate and had to investigate in order to discover. Their solution for now is the rather brute force one of forcing a GC when a wrapped GObject drops to a reference count of 1. The developer claims the performance impact is minimal because they are only forcing 1 GC every now and then to clean up hundreds of objects. I'll trust him on that because he's actually investigated it.

My point is that if they had to do it over, they would use a different design. In fact I remember reading about one of the Gnome developers investigating an alternative with a Mozilla developer that would avoid these problems. I'll link it if I can find the blog post again.

They trigger GCs to fix the leaks. Sounds like they painted themselves into a corner. Would they have these issues if they didn't use a garbage-collected language?

No, they wouldn't. They would have even worse issues like no extension system, fewer but more buggy/insecure applications, and a much longer development time. It would be a total disaster. Why do you think they wanted to investigate using a GC'd language in the first place, when they already had C?

Straight from the horse's mouth. They coupled the extensions too tightly with the compositor. If you consider the compositor to be critical (both for performance and reliability), perhaps you shouldn't allow extensions to replace parts of its functionality.

I said nothing against calendar applet extensions written in JavaScript. What I said is that Gnome performs poorly because it uses too much JavaScript. So what exactly are you trying to prove, that it could have been faster if the JS code wasn't used for such important things? How is that different from saying that it's slow because it's using JavaScript?

Yes, they coupled extensions too tightly with the compositor. So if they did not do that, there wouldn't be any problems. You seem to be following some weird logic like, Gnome is slow -> Gnome uses JavaScript -> JavaScript must be why Gnome is slow. Say that they wrote it in C and created lots of bugs and memory leaks and performance problems. Would you blame C or their bad design decisions?

I mean you keep saying the problem is JavaScript. But why? What specific thing about JavaScript is the problem? All I see from you are examples of design mistakes, not language flaws.

That's bollocks. If I am using Xorg, I can reload TWM, written in C some 30 years ago, without losing my work. Is Gnome Shell more reliable because it's using JS? No.

What is bollocks? You can reload Gnome Shell if you are using Xorg and not lose any work either. So clearly JS is not the problem. And no offense to TWM, but it's not doing anything remotely close to what Gnome Shell is doing. It's not a desktop environment, it's a window manager. And with the resources it would take to write a whole desktop environment in C, they would be looking for another language also, if that were their ambition.

(Keep in mind not even KDE is writing in something like plain C++. They are using Qt, and benefiting from all the work of that community, and even THEY are investigating using a more modern, dynamic language with efforts like QML. It simply takes too long to develop using older languages, and it's far too error prone)

Is it more flexible? Maybe, but that's only because they're letting extensions monkey-patch parts of the shell instead of providing decent extension points. And we've already seen what effect it has on performance.

So if they give developers the ability to completely rewrite the shell, then maybe the problem is that they gave them that flexibility in the first place, and it has nothing to do with the language choice? Maybe they should have presented a restricted API in order to prevent people from doing crazy things that they shouldn't?

[GrayShade]

Everyone who keeps memeing Gnome sucks because it uses JavaScript is making the implication that if they used a different language, their performance (or memory usage) would be better. If the replacement language had the same runtime behavior and a GC (which are the pros to using JS), and they used the same architecture, then they would have exactly the same problems.

Agreed. If you use a different GCed language and assume the same limitations like the lack of threading, you get similar performance.

No, they do not have "multiple GCs in the same app". They have two separate, independent methods of memory management which they are coupling together. In fact their issue is not even a memory leak, because the objects do get cleaned up eventually, it's just that they can take longer than you would expect because JavaScript cannot track C Objects.

Reference counting is one garbage collection method, just like the tracing garbage collection in JS. Of course, I expect you'll say that you can just as well use two different GC mechanisms in C and get the same results. But C apps tend not to do that more often than not.

My point is that if they had to do it over, they would use a different design. In fact I remember reading about one of the Gnome developers investigating an alternative with a Mozilla developer that would avoid these problems. I'll link it if I can find the blog post again.

I'm pretty sure they wouldn't have ended up with this specific design if they didn't choose to use JS. And I don't think it takes that much foresight to anticipate that combining two GCs (or one GC and reference counting) is not easy. As for an alternative design, it's not going to happen soon. Nobody is working on that.

No, they wouldn't. They would have even worse issues like no extension system, fewer but more buggy/insecure applications, and a much longer development time. It would be a total disaster.

Fewer extensions of course, but that's not necessarily a bad thing. Fewer apps I'm not sure why, but I think Gnome is already much too large -- how many music players does it need, and why do I need a selfie application to be installed in order to use the Settings app?

Why do you think they wanted to investigate using a GC'd language in the first place, when they already had C?

To lower the entry barrier for people writing extensions. That would have be nice if extensions wouldn't be able to crash the shell (especially on Wayland).

You seem to be following some weird logic like, Gnome is slow -> Gnome uses JavaScript -> JavaScript must be why Gnome is slow.

It's a large part of the problem, because introducing JS brought a lot of complexity.

Say that they wrote it in C and created lots of bugs and memory leaks and performance problems. Would you blame C or their bad design decisions?

C, in large part.

I mean you keep saying the problem is JavaScript. But why? What specific thing about JavaScript is the problem? All I see from you are examples of design mistakes, not language flaws.

The GC and lack of threading support.

What is bollocks? You can reload Gnome Shell if you are using Xorg and not lose any work either. So clearly JS is not the problem.

It's not Gnome's merit either.

So if they give developers the ability to completely rewrite the shell, then maybe the problem is that they gave them that flexibility in the first place, and it has nothing to do with the language choice?

The language choice was part of it, but not the only problem.

Maybe they should have presented a restricted API in order to prevent people from doing crazy things that they shouldn't?

It's not even always the fault of extension authors. You shouldn't be doing extensions if you're break compatibility on every release, more so if the old extensions make your desktop crash.