Thank you for all the great work.
I am not going to lie, I still miss Unity from time to time (specially the HUD), but now I feel at home on Gnome Shell and that’s in not small part thank to the hard work done by Ubuntu devs over the last couple of years.
@msdeiseroth Congrats on your thesis. I am a physicist too and I can tell what a difficult time the thesis preparation is. It gets better! Good luck in your dissertation!
I would also love to be able to help. I have noticed some performance problems (discussed on another topic and on launchpad) and it is always difficult to quantify an slight lack of smoothness.
@copong: The problem with poor multi-monitor performance in Wayland sessions is being tracked here. We (upstream and myself) hope that will be fixed this year.
@msdeiseroth: If you want to build a camera rig for measuring performance then it might be a good idea to use a higher frame rate than 60Hz. A simple and cheap solution is the PlayStation Eye camera (originally for the PS3) as that goes up to 187Hz in Linux. I used it a few years ago to measure Mir. If you were just measuring smoothness of an animation, you don’t need a camera for that as you could make a screen recording and assess positions in the video file, no camera required.
Although… if your screen is around 60Hz and the camera is an exact multiple of that then actually a 60Hz or 120Hz camera might be easier to reason about as you can just count frames.
@merlijn-sebrechts, @ppd: I have not investigated the relation to high disk load but yes I am familiar with that problem. Certainly the above link shows other people worked on it. My personal theory is that it was partly a problem in the 5.3 kernel, fixed in 5.4. Because the same issue suddenly appeared in Ubuntu 18.04 around the same time it got the 5.3 kernel. Or maybe Christian Hergert did find the main issues, I don’t know.
Thanks for the hint with the playstation eye camera, I might give it a try. However is that needed? As my screen has 60Hz, I’m not gonna miss any frame. I imagine [Moire Patters]
(https://en.wikipedia.org/wiki/Moiré_pattern) to be a problem tough.
If you were just measuring smoothness of an animation, you don’t need a camera for that as you could make a screen recording
Okay, but is that reliable? I sometimes have the impression that, depending on my overall pc load, the whole machine gets into stuttering and if the screen recorder suffers from the same I wouldn’t see this. Also I would like to trhough a bit more statistics on the whole topic. Basically like everything-you-know-about-latency-is-wrong suggested.
When I think about it, the biggest problem I would have right now is synchronization.
Okay, but is that reliable? I sometimes have the impression that, depending on my overall pc load, the whole machine gets into stuttering and if the screen recorder suffers from the same I wouldn’t see this.
If the screen recorder slows down from 60Hz to 30Hz you would probably notice that. My suggestion of using a screen recorder was only to check spatial smoothness. It can’t be used for everything.
So yes, if it is convenient then using a camera that’s the same frame rate as your monitor should work fine. It’s very handy being able to match up frames one-to-one. That’s only going to fail if they are slightly different like 59.95Hz and the other is 60.00Hz. In such a case you would get a glitch or mismatch every 20 seconds.
On the subject of screen recording, I have a magewell HDMI USB 3 capture card which I often use when reporting bugs. Here’s an example of the typical recording. https://www.youtube.com/watch?v=xh_Fux5bIhE
Would that be useful for capturing timings? It’s pretty reliable at capturing 60fps at 1080p from anything.
Why is GNOME using javascript as an interpretation layer for the mouse and gestures to begin with? I get that it is more easily extendable but I would think something so intimately tied to performance would be written using something a bit more efficient?
Unity vs gnome rabbit hole discussion. I reckon we all have our preferences. It’s a shame Unity 7 can’t be waylandified, but gnome has also come a long way since 17.10, and certainly a fair amount of it is due to Canonical getting involved in gnome again (among many contributors) and specifically @vanvugt crusade for performance.
The overview animation performance work was finished in 3.35.91 so it’s been done for some time. If you see any further improvement in 3.36.2 then great, but I don’t know why that would be.
This is the first release that I feel comfortable pointing people to and saying “this is Linux, go!”. Thank you folks for all the hard work you’ve done to make it as good as it is.
@vanvugt, the video stutter is because of the indicator-multiload or this is because the server side of the indicator-multiload is running inside the compositor thread? It’s true that the indicator-multiload is heavy and is also true the Ubuntu implementation of the indicator is really questionable right now as this is happening for all images that AppIndicator receive in the gjs side (https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/005fe8b8280c2bdb65fa5927de2e2ed60def0480/appIndicator.js#L477-L490). But a video stutter should not happens if the indicator-multiload will be running outside the compositor.
I know I am repetitive, but it is repetitive to see how the 3rd parties apps are blamed for the bad architecture of the shell. Isn’t it a good idea to finish fixing the shell architecture at once? i.e.: I think all GUI process should be moved outside the compositor thread. I’m pretty sure at less a video stutter should not occurs in that way. Thanks for sharing all the shell progress and your own work on this.
On a 4k monitor, firefox playing 4k youtube video stutters… whereas in Unity it is smooth.
So, it’s not just the problem of bug 784055 , something different to Unity is happening to the issue reporter in gnome-shell. That “something” is the point of my comment.
Edit2: To reproduce the reporter issue, just create an extension that execute an spawn command line in sync mode every 1 seconds (for example). Then open a video in firefox and you will see the video stutter. The spawn_command_line_sync it is slow enough to slowdown the compositor thread and it cause a stuttering. Any delay in the compositor thread tends to create the same effect. The indicator-multiload is complex, so it enough the delay that it introduced in the compositor for the bad effect of stuttering to occur. Of course, executing spawn_command_line_sync in a gjs application, outside the compositor thread does not generate the problem at all.
Please keep that discussion in bug 784055. Yes I agree it sounds like the shell is to blame and you can see I made changes in the bug to that effect on 2020-03-14. Nobody has had time to look into it yet – it’s a fairly new (re)discovery that gnome-shell is badly affected…
