You are here

Planet GNOME

Subscribe to Feed Planet GNOME
Planet GNOME - https://planet.gnome.org/
Përditësimi: 16 orë 6 min më parë

Jordan Petridis: Thoughts on employing PGO and BOLT on the GNOME stack

Mar, 26/03/2024 - 4:42md

Christian was looking at PGO and BOLT recently I figured I’d write down my notes from the discussions we had on how we’d go about making things faster on our stack, since I don’t have time or the resource to pursue those plans myself atm.

First off let’s start with the basics, PGO (profile guided optimizations) and BOLT (Binary Optimization and Layout Tool) work in similar ways. You capture one or more “profiles” of a workload that’s representative of a usecase of your code and then the tools do their magic to make the common hot paths more efficient/cache-friendly/etc. Afterwards they produce a new binary that is hopefully faster than the old one and functionally identical so you can just replace it.

Now already we have two issues here that arise here:

First of all we don’t really have any benchmarks in our stack, let alone, ones that are rounded enough to account for the majority of usecases. Additionally we need better instrumentation to capture stats like frames, frame-times, and export them both for sysprof and so we can make the benchmark runners more useful.

Once we have the benchmarks we can use them to create the profiles for optimizations and to verify that any changes have the desired effect. We will need multiple profiles of all the different hardware/software configurations.

For example for GTK ideally we’d want to have a matrix of profiles for the different render backends (NGL/Vulkan) along with the mesa drivers they’d use depending on different hardware AMD/Intel and then also different architectures, so additional profile for Raspberrypi5 and Asahi stacks. We might also want to add a profile captured under qemu+virtio while we are it too.

Maintaining the benchmarks and profiles would be a lot of work and very tailored to each project so they would all have to live in their upstream repositories.

On the other hand, the optimization itself has to be done during the Tree/userland/OS composition and we’d have to aggregate all the profiles from all the projects to apply them. This is easily done when you are in control of the whole deployment as we can do for the GNOME Flatpak Runtime. It’s also easy to do if you are targeting an embedded deployment where most of the time you have custom images you are in full control off and know exactly the workload you will be running.

If we want distros to also apply these optimizations and for this to be done at scale, we’d have to make the whole process automatic and part of the usual compilation process so there would be no room for error during integration. The downside of this would be that we’d have a lot less opportunities for aggregating different usecases/profiles as projects would either have to own optimizations of the stack beneath them (ex: GTK being the one relinking pango) or only relink their own libraries.

To conclude, Post-linktime optimization would be a great avenue to explore as it seems to be one of the lower-hanging fruits when it comes to optimizing the whole stack. But it also would be quite the effort and require a decent amount of work to be committed to it. It would be worth it in the long run.

Andy Wingo: hacking v8 with guix, bis

Mar, 26/03/2024 - 12:51md

Good day, hackers. Today, a pragmatic note, on hacking on V8 from a Guix system.

I’m going to skip a lot of the background because, as it turns out, I wrote about this already almost a decade ago. But following that piece, I mostly gave up on doing V8 hacking from a Guix machine—it was more important to just go with the flow of the ever-evolving upstream toolchain. In fact, I ended up installing Ubuntu LTS on my main workstations for precisely this reason, which has worked fine; I still get Guix in user-space, which is better than nothing.

Since then, though, Guix has grown to the point that it’s easier to create an environment that can run a complicated upstream source management project like V8’s. This is mainly guix shell in the --container --emulate-fhs mode. This article is a step-by-step for how to get started with V8 hacking using Guix.

get the code

You would think this would be the easy part: just git clone the V8 source. But no, the build wants a number of other Google-hosted dependencies to be vendored into the source tree. To perform the initial fetch for those dependencies and to keep them up to date, you use helpers from the depot_tools project. You also use depot_tools to submit patches to code review.

When you live in the Guix world, you might be tempted to look into what depot_tools actually does, and to replicate its functionality in a more minimal, Guix-like way. Which, sure, perhaps this is a good approach for packaging V8 or Chromium or something, but when you want to work on V8, you need to learn some humility and just go with the flow. (It’s hard for the kind of person that uses Guix. But it’s what you do.)

You can make some small adaptations, though. depot_tools is mostly written in Python, and it actually bundles its own virtualenv support for using a specific python version. This isn’t strictly needed, so we can set the funny environment variable VPYTHON_BYPASS="manually managed python not supported by chrome operations" to just use python from the environment.

Sometimes depot_tools will want to run some prebuilt binaries. Usually on Guix this is anathema—we always build from source—but there’s only so much time in the day and the build system is not our circus, not our monkeys. So we get Guix to set up the environment using a container in --emulate-fhs mode; this lets us run third-party pre-build binaries. Note, these binaries are indeed free software! We can run them just fine if we trust Google, which you have to when working on V8.

no, really, get the code

Enough with the introduction. The first thing to do is to check out depot_tools.

mkdir src cd src git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

I’m assuming you have git in your Guix environment already.

Then you need to initialize depot_tools. For that you run a python script, which needs to run other binaries – so we need to make a specific environment in which it can run. This starts with a manifest of packages, is conventionally placed in a file named manifest.scm in the project’s working directory, though you don’t have one yet, so you can just write it into v8.scm or something anywhere:

(use-modules (guix packages) (gnu packages gcc)) (concatenate-manifests (list (specifications->manifest '( "bash" "binutils" "clang-toolchain" "coreutils" "diffutils" "findutils" "git" "glib" "glibc" "glibc-locales" "grep" "less" "ld-gold-wrapper" "make" "nss-certs" "nss-mdns" "openssh" "patch" "pkg-config" "procps" "python" "python-google-api-client" "python-httplib2" "python-pyparsing" "python-requests" "python-tzdata" "sed" "tar" "wget" "which" "xz" )) (packages->manifest `((,gcc "lib")))))

Then, you guix shell -m v8.scm. But you actually do more than that, because we need to set up a container so that we can expose a standard /lib, /bin, and so on:

guix shell --container --network \ --share=$XDG_RUNTIME_DIR --share=$HOME \ --preserve=TERM --preserve=SSH_AUTH_SOCK \ --emulate-fhs \ --manifest=v8.scm

Let’s go through these options one by one.

  • --container: This is what lets us run pre-built binaries, because it uses Linux namespaces to remap the composed packages to /bin, /lib, and so on.

  • --network: Depot tools are going to want to download things, so we give them net access.

  • --share: By default, the container shares the current working directory with the “host”. But we need not only the checkout for V8 but also the sibling checkout for depot tools (more on this in a minute); let’s just share the whole home directory. Also, we share the /run/user/1000 directory, which is $XDG_RUNTIME_DIR, which lets us access the SSH agent, so we can check out over SSH.

  • --preserve: By default, the container gets a pruned environment. This lets us pass some environment variables through.

  • --emulate-fhs: The crucial piece that lets us bridge the gap between Guix and the world.

  • --manifest: Here we specify the list of packages to use when composing the environment.

We can use short arguments to make this a bit less verbose:

guix shell -CNF --share=$XDG_RUNTIME_DIR --share=$HOME \ -ETERM -ESSH_AUTH_SOCK -m manifest.scm

I would like it if all of these arguments could somehow be optional, that I could get a bare guix shell invocation to just apply them, when run in this directory. Perhaps some day.

Running guix shell like this drops you into a terminal. So let’s initialize depot tools:

cd $HOME/src export VPYTHON_BYPASS="manually managed python not supported by chrome operations" export PATH=$HOME/src/depot_tools:$PATH export SSL_CERT_DIR=/etc/ssl/certs/ export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt gclient

This should download a bunch of things, I don’t know what. But at this point we’re ready to go:

fetch v8

This checks out V8, which is about 1.3 GB, and then probably about as much again in dependencies.

build v8

You can build V8 directly:

# note caveat below! cd v8 tools/dev/gm.py x64.release

This will build fine... and then fail to link. The precise reason is obscure to me: it would seem that by default, V8 uses a whole Debian sysroot for Some Noble Purpose, and ends up linking against it. But it compiles against system glibc, which seems to have replaced fcntl64 with a versioned symbol, or some such nonsense. It smells like V8 built against a too-new glibc and then failed trying to link to an old glibc.

To fix this, you need to go into the args.gn that was generated in out/x64.release and then add use_sysroot = false, so that it links to system glibc instead of the downloaded one.

echo 'use_sysroot = false' >> out/x64.release/args.gn tools/dev/gm.py x64.release

You probably want to put the commands needed to set up your environment into some shell scripts. For Guix you could make guix-env:

#!/bin/sh guix shell -CNF --share=$XDG_RUNTIME_DIR --share=$HOME \ -ETERM -ESSH_AUTH_SOCK -m manifest.scm -- "$@"

Then inside the container you need to set the PATH and such, so we could put this into the V8 checkout as env:

#!/bin/sh # Look for depot_tools in sibling directory. depot_tools=`cd $(dirname $0)/../depot_tools && pwd` export PATH=$depot_tools:$PATH export VPYTHON_BYPASS="manually managed python not supported by chrome operations" export SSL_CERT_DIR=/etc/ssl/certs/ export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt exec "$@"

This way you can run ./guix-env ./env tools/dev/gm.py x64.release and not have to “enter” the container so much.

notes

This all works fine enough, but I do have some meta-reflections.

I would prefer it if I didn’t have to use containers, for two main reasons. One is that the resulting build artifacts have to be run in the container, because they are dynamically linked to e.g. /lib, at least for the ELF loader. It would be better if I could run them on the host (with the host debugger, for example). Using Guix to make the container is better than e.g. docker, though, because I can ensure that the same tools are available in the guest as I use on the host. But also, I don’t like adding “modes” to my terminals: are you in or out of this or that environment. Being in a container is not like being in a vanilla guix shell, and that’s annoying.

The build process uses many downloaded tools and artifacts, including clang itself. This is a feature, in that I am using the same compiler that colleagues at Google use, which is important. But it’s also annoying and it would be nice if I could choose. (Having the same clang-format though is an absolute requirement.)

There are two tests failing, in this configuration. It is somehow related to time zones. I have no idea why, but I just ignore them.

If the build system were any weirder, I would think harder about maybe using Docker or something like that. Colleagues point to distrobox as being a useful wrapper. It is annoying though, because such a docker image becomes like a little stateful thing to do sysadmin work on, and I would like to avoid that if I can.

Welp, that’s all for today. Hopefully if you are contemplating installing Guix as your operating system (rather than just in user-space), this can give you a bit more information as to what it might mean when working on third-party projects. Happy hacking and until next time!

Jan Lukas Gernert: Newsflash 3.2

Hën, 25/03/2024 - 11:34md

Another small feature update just in time for gnome 46.

Subscribe via CLI

Lets start with something that already went into version 3.1.4: you can subscribe to feeds via CLI now. The idea is that this is a building block for seamlessly subscribing to websites from within a browser or something similar. Lets see how this develops further.

Scrap all new Articles of a Feed

If Gitlab upvotes is a valid metric, this feature was the most requested one so far. Feed settings gained a new toggle to scrap the content of new articles. The sync will complete normally and in a second operation Newsflash tries to download the full content of all new articles in the background.

This is especially useful when there is no permanent internet connection. Now you can let Newsflash sync & download content while on WiFi and read the complete articles later even without an internet connection.

Update Feed URL

The local RSS backend gained the ability to update the URL where the feed is located (see the screenshot above). Sadly none of the other services support this via their APIs as far as I know.

Clean Database

The preferences dialog gained the ability to drop all old article and “vacuum” the database right away. Depending on the size of the database file this can take a few seconds, that’s why it is not done in the background during normal operations yet.

(btw: I’m not sure if I should keep the button as “destructive-action”) Internal Refactoring

Just a heads up that a lot of code managing the loading of the article list and keeping track of the displayed article and its state was refactored. If there are any regressions, please let me know.

Profiling

Christian Hergerts constant stream of profiling blog posts finally got to me. So I fired up sysprof. Fully expecting to not be knowledgeable enough to draw any meaningful conclusions from the data. After all, the app is pretty snappy on my machine ™, so any improvements must be hard to find and even harder to solve. But much to my surprise about 30 minutes later two absolutely noticeable low hanging fruit performance problems were discovered and fixed.

So I encourage everyone to just try profiling your code. You may be surprised what you find.

Adwaita Dialogs & Removing Configurable Shortcuts

Of course this release makes use of the new Adwaita Dialogs. For all the dialogs but one:

Configuring custom keybindings still spawns a new modal window. Multiple overlapping dialogs isn’t the greatest thing in the world. This and another annoying issue made me think about removing the feature from Newsflash completely.

The problem is that all shortcuts need to be disabled whenever the user is about to enter text. Otherwise the keybindings with a single letter cannot be entered as text.

All major feed readers (feedly, innoreader, etc) have a fixed set of cohesive keyboard shortcuts. I’ve been thinking about either having 2-3 shortcut configurations to choose from or just hard-coding keybindings all together.

I’d like to hear your thoughts. Do you use custom shortcuts? Would you be fine with a well thought out but hard-coded set of shortcuts? Would you prefer to choose from a few pre-defined shorcut configurations? Let me know, and help me find the best keybindings for all the actions that can be triggered via keyboard.

Christian Hergert: GNOME 45/46 Retrospective

Hën, 25/03/2024 - 4:20pd

My creative work is more aligned to GNOME cycles than years. Now that GNOME 46 is is out it’s a good time to look back at some of the larger things I did during those cycles.

Fedora and Frame Pointers

2023 kicked off with quite a kerfuffle around frame pointers.

Many people appear to have opinions on the topic though very few are aware of the trade-offs involved or the surface area of the problem domain. I spent quite some time writing articles to both educate and ultimately convince the Fedora council that enabling them is the single best thing they could do to help us make the operating system significantly faster release-to-release.

Much to my surprise both Ubuntu and Arch are choosing to follow.

Early this year I published an article in Fedora Magazine on the topic.

Futures, Fibers and Await for C

I still write a lot of C and have to integrate with a lot of C in my day to day work. Though I really miss asynchronous programming from other languages like when I was working on Mono all those years. Doing that sort of programming in C with the GObject stack was always painful due to the whole async/finish flow.

For decades we had other ways in C but none of them integrated well with GObject and come with their own sort of foot-guns.

So I put together libdex which could do futures/promises, fibers (including on threads), lock-free work-stealing among thread-pools, io_uring integration, asynchronous semaphores, channels, and more.

It’s really changed how I write C now especially with asychronous workflows. Being able to await on any number of futures which suspend your fiber is so handy. It reminds me a lot of the CCR library out of the Microsoft Robotic Labs way back when. I especially love that I can set up complex “if-these-or-that” style futures and await on them.

I think the part I’m most proud of is the global work queue for the thread-pool. Combining eventfd with EFD_SEMAPHRE and using io_uring worked extremely well and doesn’t suffer the thundering herd problem that you’d get if you did that with poll() or even epoll(). Being able to have work-stealing and a single worker wake up as something enters the global queue was not something I could do 20 years ago on Linux.

Where this advanced even further is that it was combined with a GMainContext on the worker threads. That too was not something that worked well in the past meaning that if you used threads you had to often forgo any sort of scheduled/repeated work.

Sysprof

Now that I was armed with actually functioning stack traces coming from the Linux perf subsystem it was time to beef up Sysprof.

Pretty much everything but the capture format was rewritten. Primarily because the way containers are constructed on Linux broke every assumption that profilers written 10 years ago had. Plus this was an opportunity to put libdex through its paces and it turned out great.

Correlating marks across GTK, GLib, and Mutter was extremely valuable.

Though the most valuable part is probably the addition of flamegraphs.

Search Providers

To test out the Sysprof rewrite I took a couple weeks to find and fix performance issues before the GNOME release. That uncovered a lot of unexpected performance issues in search providers. Fixes got in, CPU cycles were salvaged. Projects like Photos, Calculator, Characters, Nautilus, and libgweather are all performing well now it seems. I no longer find myself disabling search providers on new GNOME installations.

This work also caught JXL wallpapers adding double-digit seconds to our login time. That got pushed back a release while upstream improved GdkPixbuf loader performance.

GNOME Settings Daemon

Another little hidden memory stealer was gnome-settings-daemon because of all the isolated sub-daemons it starts. Each of these were parsing the default theme at startup which is fallout from the Meson build system handover. I had fixed this many years ago and now it works again to both save a small amount (maybe 1-3mb each) of memory for each process and reduced start-up time.

libmks

At one point I wanted to see what it would take to get Boxes on GTK 4. It seemed like one of the major impediments was a GTK 4 library to display as well as handle input (mouse, keyboard). That was something I worked on considerably in the past during my tenure at a large virtualization company so the problem domain is one I felt like I could contribute to.

I put together a prototype which led me to some interesting findings along the way.

Notably, both Qemu and the Linux kernel virtio_gpu drivers were not passing damage regions which prevented GTK from doing damage efficiently. I pointed out the offending code to both projects and now those are fixed. Now you can use the drm backend in a Qemu VM with VirGL and virtio_gpu and have minimal damage all the way through the host.

That work then got picked up by Bilal and Benjamin which has resulted in new APIs inside of GTK and consumed from libmks to further optimize damage regions.

Qemu however may still need to break it’s D-Bus API to properly pass DMA-BUF modifiers.

GtkExpression Robustness

While working on Sysprof I ran into a number of issues with GtkExpression and GObject weak-ref safety. When you do as much threading as Sysprof does you’re bound to break things. Thankfully I had to deal with similar issues in Builder years ago so I took that knowledge to fix GtkExpression.

By combining both a GWeakRef and a GWeakNotify you can more safely track tertiary object disposal without races.

GObject Type-System Performance

Also out of the Sysprof work came a lot flamegraphs showing various GType checking overhead. I spent some time diving in and caching the appropriate flags so that we save non-trivial percentage of CPU there.

My nearly decade desire to get rid of GSlice finally happened for most platforms. If you want really a really fast allocator that can do arenas well, I suggest looking into things like tcmalloc.

systemd-oomd

Also out of the Sysprof work came a discovery of systemd-oomd waking up to often and keeping my laptops from deeper sleep. That got fixed upstream in systemd.

Manuals

One prototype I created was around documentation viewers and I’m using it daily now.

I want to search/browse documentation a bit differently than how devhelp and other documentation sites seem to work. It indexes everything into SQLite and manages that in terms of SDKs. Therefore things like cross-referencing between releases is trivial. Currently it can index your host, jhbuild, and any org.gnome.Sdk.Docs Flatpak SDK you’ve installed.

This too is built on libdex and Gom which allows for asynchronous SQLite using GObjects which are transparently inflated from the database.

Another fun bit of integration work was wrapping libflatpak in a Future-based API. Doing so made writing the miners and indexers much cleaner as they were written with fibers.

Gom

A decade or more ago I made a library for automatically binding SQLite records to GObjects. I revamped it a bit so that it would play well with lazy loading of objects from a result set.

More recently it also saw significant performance improvements around how it utilizes the type system (a theme here I guess).

libpanel

Writing an application like GNOME Builder is a huge amount of work. Some of that work is just scaffolding for what I lovingly consider Big Fucking Applications. Things like shortcut engines, menuing systems, action management, window groups and workspaces, panels, document grids, and more.

A bunch of that got extracted from Builder and put into libpanel.

Additionally I made it so that applications which use libpanel can still have modern GNOME sidebar styling. Builder uses this for its workspace windows in GNOME 46 and contributes to it’s modern look-and-feel.

libspelling

One missing stair that was holding people back from porting their applications to GTK 4 was spellcheck. I already had a custom spellchecker for GNOME Text Editor and GNOME Builder which uses an augmented B+Tree I wrote years ago for range tracking.

That all was extracted into libspelling.

Text Editor

One of the harder parts to keep working in a Text Editor, strangely enough, is task cancellation. I took some time to get the details right so that even when closing tabs with documents loading we get those operations cancelled. The trickier bit is GtkTextView doing forward line validation and sizing.

But that all appears to work well now.

I also tweaked the overview map considerably to make things faster. You need to be extremely careful with widgets that produce so many render nodes which overlap complex clipping. Doubly so when you add fractional scaling and the border of a window can cross two pixels of the underlying display.

GNOME Builder got similar performance treatments.

Frame Jitters

While tracking down GTK renderer performance for GTK 4.14 I spent a lot of timing analyzing frame timings in Sysprof.

First, I noticed how Mutter was almost never dispatching events on time and mostly around 1 millisecond late. That got fixed with a timerfd patch to Mutter which tightens that up. At 120hz and higher that extra millisecond becomes extremely useful!

After fixing Mutter I went to the source and made patches taking two different strategies to see which was better. One used timerfd and the other using ppoll(). Ultimately, the ppoll() strategy was better and is now merged in GLib. That will tighten up every GLib-based application including the GdkFrameClock.

I also added support for the Wayland presentation-time protocol in GTK’s Wayland back-end so that predicted frame times are much more accurate.

GLib

In addition to the ppoll() work above in GLib I also did some work on speeding up how fast GMainContext can do an iteration of the main loop. We were doing extraneous read() on our eventfd each pass resulting in extra syscalls. I also optimized some GList traversals while I was there.

I separated the GWeakRef and GWeakNotify lists inside of GObject’s weak ref system so that we could rely on all pointers being cleared before user callback functions are executed. This predictability is essential for building safety at higher levels around weak references.

GtkSourceView

There were a few more cases in GtkSourceView that needed optimization. Some of them were simpler like premixing colors to avoid alpha blends on the GPU. In the end, applications like Text Editor should feel a lot snappier in GNOME 46 when combined with GTK 4.14.1 or newer.

GTK

I spent some time at the end of the 46 cycle aiding in the performance work on NGL/Vulkan. I tried to lend a hand based on the things I remember helping/hurting/doing nothing while working on the previous GL renderer. In all, I really like where the new NGL/Vulkan renderers are going.

While doing some of that work I realized that finalizing our expired cache entries of lines for the textview was reducing our chance at getting our frames submitted before their deadline. So a small patch later to defer that work until the end of the frame cycle helps considerably.

Another oddity that got fixed was that we were snapshotting textview child widgets (rarely used) twice in the GtkTextView thanks to an observant bug reporter. This improved the gutter rendering times for things like GtkSourceView.

I also tried to help define some of the GtkAccessibleText API so we can potentially be lazy from widget implementations. The goal here is to have zero overhead if you’re not using accessibility technology and still be fast if you are.

I also added a fast path for the old GL renderer for masked textures. But that never saw a release as the default renderer now that NGL is in place, so not such a big deal. It helped for Ptyxis/VTE while it lasted though.

GSK also saw a bunch of little fixes to avoid hitting the type system so hard.

libpeas 2.0

Libpeas got a major ABI bump which came with a lot of cleaning up of the ABI contracts. But even better, it got a GJS (SpiderMonkey) plugin loader for writing plugins in JavaScript.

GNOME Builder uses this for plugins now instead of PyGObject.

VTE Performance

As my monitor resolution got higher my terminal interactivity in Builder was lessened. Especially while on Wayland. It got to the point that latency was causing me to miss-type frequently.

Thankfully, I had just finished work on Sysprof so I could take a look.

Builder is GTK 4 of course, and it turned out VTE was drawing with Cairo and therefore spending significant time on the CPU drawing and significant memory bandwidth uploading the full texture to the GPU each frame.

Something I did find funny was how up in arms people got about a prototype I wrote to find the theoretical upper bounds of PTY performance for a terminal emulator. How dare I do actual research before tackling a new problem domain for me.

In the end I finally figured out how to properly use GskTextNode directly with PangoGlyphString to avoid PangoLayout. A trick I’d use again in GtkSourceView to speed up line number drawing.

Along with modernizing the drawing stack in VTE I took the chance to optimize some of the cross-module performance issues. VTE performance is in pretty good shape today and will certainly get even better in it’s capable maintainers hands. They were extremely friendly and helpful to a newcomer showing up to their project with grand ideas of how to do things.

GNOME Terminal

To validate all the VTE performance work I also ported the venerable GNOME Terminal to GTK 4. It wasn’t quite ready to ship in concert with GNOME 46 but I’m feeling good about it’s ability to ship during GNOME 47.

Ptyxis

For years I had this prototype sitting around for a container-based terminal built on top of the Builder internals. I managed to extract that as part of my VTE performance work.

It’s a thing now, and it’s pretty good. I can’t imagine not using it day-to-day now.

VTE Accessibility

Now that I have a GTK 4 terminal application to maintain the only responsible thing for me to do is to make sure that everyone can use it. So I wrote a new accessibility layer bridging VteTerminal to GtkAccessibleText in GTK.

Podman and PTY

While working on Ptyxis I realized that Podman was injecting an extra PTY into the mix. That makes foreground process tracking extremely difficult so I advocated the ability to remove it from Podman. That has now happened so in future versions of Ptyxis I plan to prod Podman into doing the right thing.

GNOME Builder

All sorts of nice little quality of life improvements happened in Builder. More control over the build pipeline and application runtime environment make it easier to integrate with odd systems and configurations.

The terminal work in Ptyxis came back into Builder so we got many paper cuts triaged. You’ll also notice many new color palettes that ship with Builder which were generated from palettes bundled with Ptyxis.

Memory usage has also been reduced even further.

Removing Twitter, Mastodon, and Matrix

I removed my social media accounts this year and it’s lovely. Cannot recommend it enough.

Christian Hergert: Debug Builds and GPUs

Dje, 24/03/2024 - 8:35md

Decades ago, when you wanted to run debug builds for UI applications, things were incredibly slow.

First you’d wait minutes for the application to present a window. Then wait tens of seconds for each frame to render. You were extremely lucky if Valgrind caught the issue while you exercised the UI.

Things have gotten much better due to movement in two different directions.

In one direction GCC and Clang got compiler integration for sanitizers like ASAN. Instead of relying on extreme amounts of emulation in Valgrind compilers can insert the appropriate checks, canaries, and memory mapping tricks to catch all sorts of behavior.

In the other direction we’ve started drawing modern UI toolkits with the GPU. The idea here is that if the work is dispatched to the GPU, there is less for the CPU to run and therefore less work for the sanitizers and/or Valgrind to do.

Don’t let that fool you though. A lot of specialized work is done on the CPU still to allow those GPUs to go fast. You trade off framebuffer updates and huge memory bus transfers for more complex diffing, batching and reordering operations, state tracking, occasional texture uploads, and memory bandwidth for vertex buffers and the likes.

Here I’ve compiled all the hot parts of a GTK application with the address sanitizer. That includes GLib/GIO/GObject, Harfbuzz, Pango, and GTK. The application is also running with GSK_DEBUG=full-redraw to ensure we redraw the entire window every single frame with full damage. We use GDK_DEBUG=no-vsync to let it run as fast as it can rather than block waiting for the next vblank.

And still, GTK can produce hundreds of frames per second.

Truly magical.

Dave Patrick Caberto: Kooha 2.3 Released!

Dje, 24/03/2024 - 5:29pd

Kooha is a simple screen recorder for Linux with a minimal interface. You can simply click the record button without having to configure a bunch of settings.

While we strive to keep Kooha simple, we also want to make it better. This release, composed of over 300 commits, is focused on quality-of-life improvements and bug fixes.

This release includes a refined interface, improved area selection, more informative notifications, and other changes. Read on to learn more about the new features and improvements.

New Features and Improvements Refined Interface

The main screen now has a more polished look. It now shows the selected format and FPS. This makes it easier to see the current settings at a glance, without having to open the settings window.

Other than that, progress is now shown when flushing the recording. This gives a better indication when encoding or saving is taking longer than expected.

Furthermore, the preferences window is also improved. It is now more descriptive and selecting FPS is now easier with a dropdown menu.

Improved Area Selection

The area selection window is now resizable. You can now resize the window to fit your screen better. Additionally, the previously selected area is now remembered across sessions. This means that if you close Kooha and open it again, the area you selected will be remembered. Other improvements include improved focus handling, sizing fixes, better performance, and a new style.

More Informative Notifications

Record-done notifications now show the duration and size of the recorded video. This is inspired by GNOME Shell screencast notifications.

Moreover, the notification actions now work even when the application is closed.

Other Changes

Besides the mentioned features, this release also includes:

  • Logout and idle are now inhibited while recording.
  • The audio no longer stutters and gets corrupted when recording for a long time.
  • The audio is now recorded in stereo instead of mono when possible.
  • The recordings are no longer deleted when flushing is canceled.
  • Incorrect output video orientation on certain compositors is now fixed.
  • Performance and stability are improved.
Getting Kooha 2.3

Kooha is available on Flathub. You can install it from there, and since all of our code is open-source and can be freely modified and distributed according to the license, you can also download and build it from source.

Closing Words

Thanks to everyone who has supported Kooha, be it through donations, bug reports, translations, or just using it. Your support is what keeps this project going. Enjoy the new release!

Tobias Bernard: Mini GUADEC 2024: We have a Venue!

Pre, 22/03/2024 - 7:51md

We’ve had a lot of questions from people planning to attend this year’s edition of the Berlin Mini GUADEC from outside Berlin about where it’s going to happen, so they can book accommodation nearby. We have two good news on that front: First, we have secured (pending a few last organizational details) a very cool venue, and second: The venue has a hostel next to it, so there’s the possibility to stay very close by for cheap :)

Come join us at Regenbogenfabrik

The event will happen at Regenbogenfabrik in Kreuzberg (Lausitzerstraße 21a). The venue is a self-organized cultural center with a fascinating history, and consists of, in addition to the event space, a hostel, bike repair and woodworking workshops, and a kindergarten (lucky for us closed during the GUADEC days).

The courtyard at Regenbogenfabrik

Some of the perks of this venue:

  • Centrally located (a few blocks from Kottbusser Tor)
  • We can stay as late as we want (no being kicked out at 6pm!)
  • Plenty of space for hacking
  • Lots of restaurants, bars, and cafes nearby
  • Right next to the Landwehrkanal and close to Görlitzer Park
  • There’s a ping pong table!

Regenbogenfabrik on Openstreetmap

Stay at the venue

If you’re coming to Berlin from outside and would like to stay close to the venue there’s no better option than staying directly at the venue: We’ve talked to the Regebogenfabrik Hostel, and there’s still somewhere around a dozen spots available during the GUADEC days (in rooms for 2, 3, or 8 people).

Prices range between 20 and 75 Euro per person per night, depending on the size of the room. You can book using the form here (german, but Firefox Translate works well these days :) ).

As the organizing team we don’t have the capacities to get directly involved in booking the accommodations, but we’re in touch with the hostel people and can help with coordination.

Note: If you’re interested in staying at the hostel act fast, because spots are limited. To be sure to get one of the open spots, please book by next Tuesday (March 26th) and mention the codeword “GNOME” so they know to put you in rooms with other GUADEC attendees.

Also, if you’re coming don’t forget to add your name to the attendee list on Hedgedoc, so we know roughly how many people are coming :)

If you have any other questions feel free to join our Matrix room.

See you in Berlin!

Felix Häcker: #140 Forty-six!

Pre, 22/03/2024 - 1:00pd

Update on what happened across the GNOME project in the week from March 15 to March 22.

This week we released GNOME 46!

This new major release of GNOME is full of exciting changes, such as a new global file search, an enhanced Files app, improved online accounts with OneDrive support, remote login via RDP, improved accessibility, experimental variable refresh rate (VRR) support and so much more! See the GNOME 46 release notes and developer notes for more information.

Readers who have been following this site will already be aware of some of the new features. If you’d like to follow the development of GNOME 47 (Fall 2024), keep an eye on this page - we’ll be posting exciting news every week!

Sovereign Tech Fund

Sonny announces

As part of the GNOME STF (Sovereign Tech Fund) initiative, a number of community members are working on infrastructure related projects.

Besides helping with the GNOME 46 release (congrats everyone!); here are the highlights for the past week

This week we welcome Jerry, Tom, Neill and Jude of Codethink into the team.

Jerry and Tom got started with finishing sysupdate: Implement dbus service. This will allow apps such as GNOME Software, KDE Discover, … to support systemd-sysupdate

Neill got started making GNOME openQA more robust with

Julian implemented 9 new properties for notifications in xdg-desktop-portal such as icon (via fd), sound, actions, markup-body, …

Julian worked on making notifications in xdg-desktop-portal forward compatible by allowing unknown properties.

Dorota is working on an interface for global shortcuts in Mutter/GNOME Shell suitable for the global shortcuts portal (except listing shortcuts)

Dhanuka has been testing the Rust DBus Secret Service provider implementation in oo7 to replace GNOME Keyring

Jonas made improvements in audio integration #25, #26

Alice resumed work on CSS custom properties / variables support in GTK; animations are now supported.

Andy made a protoype to allow opening URLs with apps. The goal is for an app such as GNOME Maps to advertise support for and handle openstreetmap.org or google.com/maps URLs. Your browser doesn't support embedded videos, but don't worry, you can download it and watch it with your favorite video player!

GNOME Core Apps and Libraries GLib

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall announces

Christian Hergert added support for sub-millisecond timeouts in GLib using ppoll() (https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3958)

Philip Withnall reports

Sudhanshu Tiwari has made a start on porting some of the GIO documentation comments to gi-docgen in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3969

Emmanuele Bassi reports

JSON-GLib, the library for parsing and generating JSON data, is now capable of strict compliance with the JSON specification. To avoid breaking backward compatibility, strictness must be explicitly enabled by setting the JsonParser:strict property, or using the --strict option for the json-glib-validate command line tool. To enforce strict compliance, JSON-GLib now includes a whole JSON conformance test suite.

GNOME Incubating Apps

Sophie (she/her) announces

Decibels has been accepted into the GNOME Incubator. The GNOME incubation process is for apps that are designated to be accepted into GNOME Core or GNOME Development Tools if they reach the required maturity.

Decibels is a basic audio player that is supposed to fill the gap of GNOME currently not having a Core app that is designed to open single audio files. The incubation progress will be tracked in this issue.

GNOME Circle Apps and Libraries

Tobias Bernard reports

Railway has been accepted into GNOME Circle. It allows you to easily look up travel information across rail networks and borders without having to use multiple different websites. Congratulations!

Workbench

A sandbox to learn and prototype with GNOME technologies.

Sonny announces

Workbench 46 is out on Flathub! Here are the highlights

Everybody is excited about them so I’ll start by saying you can try libadwaita 1.5 adaptive dialogs with the new “Dialog” and “Message Dialogs” demos in the Library.

Workbench now shows inline diagnostics for Rust and Python.

A new Library demo “Snapshot” was added to demonstrate one of GTK4 coolest feature.

26 additional demos have been ported to Python

5 additional demos have been ported to Vala

The GNOME 46 release notes includes all the changes between Workbench 45 and 46.

Thank you to all contributors Your browser doesn't support embedded videos, but don't worry, you can download it and watch it with your favorite video player!

Fretboard

Look up guitar chords

Brage Fuglseth reports

Happy release week! Like many other apps, Fretboard has been updated to the GNOME 46 platform, taking advantage of the many platform improvements that have happened this cycle. It also recently gained the ability to notify you when there are no available variants of a chord in its internal chord set, prompting you to reach out and help improve it.

As always, you can get Fretboard on Flathub.

Third Party Projects

robert.mader announces

Livi 0.1.0 is now available on Flathub. Bundled with Gstreamer 1.24 and build against the GTK 4.14 it is the first desktop-targeting app to enable zero-copy Video playback by default in the Wayland ecosystem. Doing so enables highly power-efficient playback, closing the gap to other OSs or embedded environments. We expect quite a few people to hit driver bugs in the beginning - so in order to pave the way for other apps to pick up the technology, please help testing on you devices :)

Alain reports

Planify has received several updates this week, including bug fixes and design enhancements.

As part of the effort to apply for Gnome Circle, the user interface has been updated with new icons, design elements, and typography.

What’s new:

  • Performance of synchronization with Nextcloud has been improved.
  • It’s now possible to select the Pinboard view as the homepage.
  • You can now add a task to the Pinboard view from the contextual menu.
  • Various reported bugs have been fixed.

Akshay Warrier reports

Biblioteca 1.3 is now available on Flathub!

This release comes with several additions and improvements such as:

  • Added docs for GLib/Gio/GObject
  • Added support for web content
  • Improved searching UI
  • Added support for keyboard navigation in the sidebar
  • Added zoom buttons to the primary menu
  • Added shortcuts to view open tabs and toggle sidebar

Markus Göllnitz announces

Rumour has it there was a recent release of Usage – complete with leaked release screenshots.

  • So far, It looks like, it features an indicator for applications running in background.
  • Apparently, it is even displaying individual Android applications when you run Waydroid, now. That is something.
  • On top of it, I would say, the split of the performance view into processor and memory and the subsequent use of flat header bars works quite well.

Find it at a distro near you.

FineFindus says

I’m happy to announce the first release of Hieroglyphic, a forked and updated version of TeX-Match, which helps to find LaTeX symbols by drawing them. It’s available for download on Flathub.

Kooha

Elegantly record your screen.

Dave Patrick says

Kooha 2.3 is now released on Flathub! While there are no groundbreaking new features, this release is focused more on fixes and quality-of-life improvements.

The following features and fixes are the highlights:

  • The area selector window is now resizable, making selecting an area more flexible.
  • The previously selected area is now remembered across sessions.
  • The current video format and FPS configurations are now visible in the main view.
  • The recording done notification now shows the duration and size of the recording.
  • Progress is now shown while flushing the recording.
  • Recording in stereo rather than in mono is now more preferred.
  • Audio stutters on long recordings are now properly fixed.
  • The preferences dialog is now more descriptive and provides a more convenient FPS selection box.
  • Incorrect recording orientation on certain compositors is now fixed.

For a more detailed changelog, check out the full release notes.

Flare

Chat with your friends on Signal.

schmiddi reports

Flare version 0.14.1 was released. This release includes updating the dialogs to the new adwaita adaptive dialogs. Furthermore, we also have a new “new channel” dialog and channel information dialog. This release also contains a hotfix for newly linked devices not working with groups and another minor fix for an error in certain groups.

Blueprint

A markup language for app developers to create GTK user interfaces.

Sonny announces

Blueprint; the markup language and tooling for GTK is out in version 0.12

Here are the highlights ✨

Brand-new formatter to keep files tidy

AdwAlertDialog are supported

Emit warnings for deprecated features in GTK, GLib, etc

New IDE integration features

  • document symbols
  • “Go to definitions”
  • Code action for importing missing namespace

We also celebrate 70 applications on Flathub built with Blueprint.

Events

Deepesha Burse reports

The deadline for the GUADEC 2024 Call for Participation is closing soon! This year’s conference will take place in Denver, Colorado, from July 19th to July 24th and we encourage all interested contributors, speakers, and participants to submit their proposals before the deadline on 24th March. This is an excellent opportunity to share your insights, experiences, and ideas with the GNOME community and contribute to the success of GUADEC 2024. Please visit guadec.org to submit your proposals. If you have any questions or need assistance, feel free to reach out to the organizing committee at guadec@gnome.org. We look forward to receiving your submissions and seeing you at GUADEC 2024 in Denver and online!

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

Christian Hergert: BOLT’ing Libraries

Enj, 21/03/2024 - 8:06md

I did a little experimenting with BOLT today to optimize libraries post-link.

I’m not an expert on it or anything, but it seems to allow you to reorder functions in your executable/library based on feedback from perf record and some special post-processing. You can merge multiple runs together in case you have different workloads you’d like to optimize for. But in the end, hot functions get placed near each other to reduce instruction cache pressure.

In all, it says you can expect gains up-to about 7% which fits in line with my experiment. For example, I open gnome-text-editor with a large C file, the overview map enabled, and syntax highlighting on. Then hold down Page Down to the bottom, Page Up to the top, and then Page Down back to the bottom.

The first pass through the source code is usually a little slower because you’re doing the incremental syntax-highlighting process.

After using BOLT on Pango, I saw roughly a 6% reduction in time spent measuring text (which is one of the most expensive parts of the overview map).

To test this out, I did have to play with my CFLAGS to have -Wl,--emit-relocs linker option. After that and a meson setup --wipe $SRCDIR things seem to work as expected.

Trying it For Yourself

sudo dnf install llvm-bolt perf

perf record -e cycles:u -j any,u -o perf.data -- gnome-text-editor

# you can do this for any of the binaries
perf2bolt -p perf.data -o perf.fdata ~/.jhbuild/lib/libpango-1.0.so

llvm-bolt ~/.jhbuild/lib/libpango-1.0.so -o libpango-1.0.so.bolt -data=perf.fdata -reorder-blocks=ext-tsp -reorder-functions=hfsort -split-functions -split-all-cold -split-eh -dyno-stats

mv libpango-1.0.so.bolt ~/.jhbuild/lib/libpango-1.0.so

Rinse and repeat.