Read more of this story at Slashdot.
Read more of this story at Slashdot.
With the release of 4.23.1, GTK’s renderer will come with a new feature that we’ve called snapping.
How does it work?Snapping is enabled by calling gtk_snapshot_set_snap(). If enabled, it will slightly adjust the placement of rectangles when drawing so that they align with the pixel grid and don’t cover half a pixel.
Content drawn with GTK is scaled automatically by the desktop’s scale factor. But with the arrival of native fractional scaling, it is no longer possible to know if content is aligned to the pixel grid.
While that is usually not a problem, there are a few cases where it is:
Sprite gridsGameeky is a learning game that plays on a grid. Unfortunately, on a fractionally scaled machine, it can end up looking like this:
Once those sprites are snapped to the pixel grid by rounding to the nearest pixel, the same image looks like this
Often Applications want to display images in a way that matches the pixels of the image 1:1 with pixels of the monitor. This is a challenge on a fractionally scaled display. Not only is it important to get the scale factor right, it’s also important to align the pixels correctly, or they will appear slightly blurry.
The use case is not just image viewers that want to offer a 1:1 zoom factor, but all applications that redirect drawing, from game emulators to viewers like Boxes or Connections.
Hardware optimizationsAnd finally, there are optimizations like graphics offload that rely on content being aligned to the pixel grid or the hardware cannot optimize them. So it is important to snap content to the pixel grid for those cases.
Why don’t we just always snap to the grid?There is one big problem with automatic snapping: smoothness. Because snapping only works on full pixels, doing slow animations causes content to jump from one pixel to the next. And that causes jitter.
The main situation where one can see this is smooth scrolling, like in this example:
https://blogs.gnome.org/gtk/files/2026/04/jitter.webm SummaryThe next GTK release will offer a new way to tame the effects of fractional scaling. Please try it out and let us know how it works!
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
While working on my GSoC project (rewriting the Pitivi timeline in Rust), I ran into an issue getting precise UI ticks that map to the absolute nanosecond timestamps of the video frames. Initially I hardcoded NTSC fractional math (24000/1001) to calculate the boundaries of frames.
This led to issues with truncated timestamps, and had a glaring issue with other framerates (like 30fps). I needed a more robust solution that could handle any framerate and provide accurate tick positions.
I assumed that I could extract the framerate directly from ges::Timeline, however there is no direct getter in the Rust bindings. After some digging, I discovered that the framerate is actually stored in the gst::Caps of the timeline's video stream as a gst::Fraction.
My ApproachThe steps I used:
I wrote a helper function to extract the framerate from the timeline:
pub fn get_fps(&self, timeline: &ges::Timeline) -> Option<(i128, i128)> { timeline .tracks() .into_iter() .find(|track| track.track_type().contains(ges::TrackType::VIDEO)) .and_then(|track| { let caps = track.restriction_caps().or_else(|| track.caps())?; let structure = caps.structure(0)?; let fps = structure.get::<gst::Fraction>("framerate").ok()?; // Extract the safe numerator and denominator Some((fps.numer() as i128, fps.denom() as i128)) }) } // ... inside the timeline injection logic: if let Some((fps_num, fps_denom)) = self.get_fps(timeline) { self.fps_num.set(fps_num.max(1) as i32); self.fps_denom.set(fps_denom.max(1) as i32); } else { // Default to 23.976 if we can't find a valid framerate caps self.fps_num.set(24_000); self.fps_denom.set(1_001); }I make some assumptions here, such as only one video track existing, and that the framerate is always present in the caps. This solution made the tick spacing and labels line up with the timeline’s actual frame boundaries at any framerate.
Read more of this story at Slashdot.
I do not always want to know what time it is. This is a slightly awkward position for someone who keeps making clocks, but there we are. Quite often the useful answer is not 17:42. It is “quarter to six”, “nearly lunch” or “you should probably start thinking about leaving”. The precise time is useful when catching trains, baking things and joining calls; the rest of the time it can be a bit much.
So I have been working on fuzzy time for a while. The first version I made was for the Pebble, which remains one of those devices that makes later technology feel slightly ashamed of itself. A small always-on screen, good battery life, physical buttons and just enough personality. It’s not tokyoflash after all.
The current versions are Fuzzy Time GB, a Wear OS watch face, and Fuzzy Clock GB, a GNOME Shell extension.
The Android version is quite a funny object internally. It is a Watch Face Format v2 face, so the APK has no app code:
android:hasCode="false"The face itself is declarative XML. Since writing thirty-six thousand lines of watch face XML by hand would be a cry for help, there is a generator which writes the cases out from the same fuzzy time rules. For every hour and every five-minute bucket it emits the condition, text and separate interactive and ambient versions.
That sounds excessive until you look at the details; and then it still sounds excessive. There are lots of pernickety things that give this the correct GB locale to my ears. “Five Past Midnight” is a real phrase. 23:58 should say “Midnight”, and if the date is visible it should be tomorrow’s date. 11:58 should say “Noon”. “O’Clock” wants different spacing and weight from “Twenty-five To”. Ambient mode wants smaller, quieter text. A round watch face leaves less room than you think it does. The watch face has a few small choices rather than a settings cathedral: warm white, cool white, soft green, dim amber; system font or Arvo; optional radial complication slots above and below the text. The range complications are deliberately arcs around the edge rather than little widgets in the middle. They can show useful things, but they should not make the face stop being mostly words and calm black space.
The GNOME version is the same idea on a different surface. It finds the existing clock label, listens to the same wall clock, respects the existing “show date” and “show weekday” settings, and changes the text. I have wanted to build something like this for years, partly because of Emmanuele Bassi’s word clock extension. That extension was great, but not quite the thing I wanted, so eventually I got around to making my own.
One of the few design decisions left that I helped on in main GNOME (which is much better now) is that the shutdown and logout dialogue only updates its timing every so often. It could update every second; the computer is quite capable of counting. But it’s much more pleasant when the number doesn’t twitch constantly while you are trying to decide whether you meant to press the button.
You can build both projects from source. I may choose to distribute them in a more structured fashion in future. The Android one is a minimal Wear OS watch face, and the GNOME one is a normal Shell extension that currently supports GNOME Shell 45 to 50.
Read more of this story at Slashdot.