Not sure what exactly is going on, but whenever Tracy is resolving symbols I'm seeing GJS code block in dlsym() hundreds of times per frame with the sort of backtrace like on the screenshot, leading to massive lag in some cases. Thankfully, TRACY_NO_SAMPLING=1 removes most of this interference.
I guess normally GJS hits some sort of cache for these hundreds of requests when it doesn't contend with Tracy? Either way, a bit unfortunate.
Trying to profile a real session running on my slower laptop today. Already found two things of interest:
1. Clutter isn't compressing touchpad swipe events, processing them one by one, taking almost 2 ms each.
2. Layout running during picking? Doesn't seem intended.
Also worked on making a COPR with Tracy-instrumented Mutter so others can record their performance problems too. I'll link that later, once someone else gives it a try and confirms that it works.
Today made buildsystem integration between Tracy and Cogl considerably less cursed, and started adding plots.
Unfortunately, I had to disable Tracy symbol collection entirely by default as the contention with whatever GJS is doing is really bad. The main thing this loses is the ability to see what's going on in zones not annotated with spans, and in wait stacks, which is occasionally useful.
Today I managed to hack together GSource instrumentation with Tracy. Now this gets into a more complex territory because it's in glib, so Tracy needs to be a separately installed shared library, and it should only start its profiling threads in the process I care about (gnome-shell) and not in all processes that use glib. Tracy has manual profiler start/stop support for this, but I had to add a function that checks whether the profiler had started, and tweak the meson build to output pkgconfig.
I swear, every single time I'm preparing release notes for one of my projects I randomly stumble upon a completely unrelated bug that's been sitting there unnoticed for months. It just happened again with niri 0.1.4, I hit a timing based crash in the screencast code that must've been there from the beginning. I'm actually glad because it means I can fix it right away, but how does this keep happening lol
Added quite a number of things into the compositor since then. It's at the point where I can somewhat-comfortably use it for working or (Wayland-only) gaming sessions.
Today I figured out how to make it run as a proper session, launched from GDM, with systemd integration and all. It even mostly works!
Also finally implemented the ability to take screenshots—this one is from a real session.
Kinda want to try my hand at the screencast portal for OBS. How hard can it be, right? 🙃
Decided to try writing a Wayland compositor for fun. Took me a few days to get things going to a video-able state.
This is scrollable tiling, heavily inspired by PaperWM (which I'm still using and very much enjoying). You've got an infinite strip of windows that you can scroll through.
It's also got dynamic workspaces which work like in GNOME Shell (the Correct™ way to do workspaces), but all monitors have workspaces.
After adding dmabuf feedbacks to niri, I stumbled upon an extremely strange performance problem when using overlay planes. One specific animation, with a GTK 4 window open, stutters, but only when going into one direction.
Spent half a day debugging it with Smithay developers. Couldn't crack it yet; for some reason an AMDGPU kernel worker just... takes a while under those specific conditions, causing delayed frames. Seems to be doing the same thing as in the normal case, just... slower somehow.
Almost done adding touchpad gesture support to Smithay!
Here you can see the pinch zoom/rotate gesture visually in gtk4-demo, then the swipe gesture only in WAYLAND_DEBUG on the right, then the hold gesture by stopping the kinetic scrolling by putting a finger on the touchpad.
I'm quite enjoying playing with the Tracy profiler. Turns out when you run the program with sudo, it records a ton of extra useful info, like CPU core scheduling, monitor VSync events, kernel context switches, what your process is blocked on.
I also annotated my compositor with Tracy Frame events for monitor VBlank cycles. I can then set a target FPS in Tracy and instantly see which frames were too slow! Both in the bar at the top, and in the main area highlighted in red.
aaaaaaaaahhhhhhhhhhh these two days were a grind but I somehow got monitor streaming working! with pipewire and dmabufs and dbus and screencast portal and everything! and it wooorkssssssssss woooooooooooooo