Looks like you put in effort to get the scaling (drawing) at pixel level. Very nice work, I hate it when I know I can get razor sharp text at native resolution. But then my eyes want something bigger, macOS upscales and I get a fuzzy picture...
Can you tell us more about the challenges in this area?
Thanks. Fractional scaling was one of the foundation of Vela: it is really one of the reasons why Vela exists. So I thinked about it since the first minute. The issue is of course that something like at 125% with logical coordinates don't always came at actual physical pixels. And even small rounding can cause blurry text.
So in Vela fractional scaling works everything in logical coordinates until the rendering stage, then it rounds to physical pixels. If you want to deep dive: https://github.com/vela-desktop/vela/blob/main/docs/renderer...
No, this is written in C (the compositor itself) and C++ (parts which talks with QT)
However, the naming problem is known and currently there is an issue open (#174)
Well, first full disclosure I'm an occasional KDE developer. Most of that code is useful and there isn't much code that is widely considered to be unpleasant to work on or doing badly on performance metrics. About Vulkan - the compositor is mostly blitting textures into rectangles - you are not going to increase fill rate much by using an API that allows faster state changes. Vulkan is a good choice for an entirely new compositor, but not using Vulkan is not really a problem for a compositor on Linux, where OpenGL won't be removed or crippled willy-nilly.
Thanks for your time, talking with a KDE developer is important to me. The reason for choosing Vulkan was about explicit control over synchronization, resource management and frame scheduling, without having to maintain also OpenGL; even though I don't exclude a software rendering fallback for VMs or something. It wasn't a first-minute choice, I realised it when I wanted to improve performance compared to other DE. Currently I'm developing a benchmark suite, this is not complete yet but I've already found out Vela around 40% lower input-to-display latency in one of my tests (compared to Plasma), apparently thanks to late latching.
Looks like you put in effort to get the scaling (drawing) at pixel level. Very nice work, I hate it when I know I can get razor sharp text at native resolution. But then my eyes want something bigger, macOS upscales and I get a fuzzy picture...
Can you tell us more about the challenges in this area?
Thanks. Fractional scaling was one of the foundation of Vela: it is really one of the reasons why Vela exists. So I thinked about it since the first minute. The issue is of course that something like at 125% with logical coordinates don't always came at actual physical pixels. And even small rounding can cause blurry text. So in Vela fractional scaling works everything in logical coordinates until the rendering stage, then it rounds to physical pixels. If you want to deep dive: https://github.com/vela-desktop/vela/blob/main/docs/renderer...
Awesome. I scanned through the renderer documentation. Automated tests for "nasty" patterns, very cool.
Cool! By any chance, is it written in either Vela[0] or Vela[1]?
0: https://vela-lang.org/
1: https://realm-labs.github.io/vela/overview/
No, this is written in C (the compositor itself) and C++ (parts which talks with QT) However, the naming problem is known and currently there is an issue open (#174)
AFAIK, KDE already does everything listed under "Fluid" and "Sharp".
You're not wrong, but at the same time KDE has to deal with a lot of legacy code from the past. Vela breaks with the past, supporting only Vulkan 1.4
Well, first full disclosure I'm an occasional KDE developer. Most of that code is useful and there isn't much code that is widely considered to be unpleasant to work on or doing badly on performance metrics. About Vulkan - the compositor is mostly blitting textures into rectangles - you are not going to increase fill rate much by using an API that allows faster state changes. Vulkan is a good choice for an entirely new compositor, but not using Vulkan is not really a problem for a compositor on Linux, where OpenGL won't be removed or crippled willy-nilly.
Thanks for your time, talking with a KDE developer is important to me. The reason for choosing Vulkan was about explicit control over synchronization, resource management and frame scheduling, without having to maintain also OpenGL; even though I don't exclude a software rendering fallback for VMs or something. It wasn't a first-minute choice, I realised it when I wanted to improve performance compared to other DE. Currently I'm developing a benchmark suite, this is not complete yet but I've already found out Vela around 40% lower input-to-display latency in one of my tests (compared to Plasma), apparently thanks to late latching.
Looks great!! but i'm a KDE fan.
I understand, well Vela integrates good with KDE Apps. I think you should give it a try
No arm support? Dang
I'm sorry currently this is more focused to Desktop computers, ARM is not a priority for early beta
Np, i'm interested in using this on Raspberry Pi devices. Thanks for the good work!