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?
BrandoDev_it 13 hours ago [-]
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...
bartvk 9 hours ago [-]
Awesome. I scanned through the renderer documentation. Automated tests for "nasty" patterns, very cool.
kstrauser 15 hours ago [-]
Cool! By any chance, is it written in either Vela[0] or Vela[1]?
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)
ahartmetz 16 hours ago [-]
AFAIK, KDE already does everything listed under "Fluid" and "Sharp".
BrandoDev_it 13 hours ago [-]
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
ahartmetz 12 hours ago [-]
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.
BrandoDev_it 12 hours ago [-]
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.
esFran 16 hours ago [-]
Looks great!! but i'm a KDE fan.
BrandoDev_it 13 hours ago [-]
I understand, well Vela integrates good with KDE Apps. I think you should give it a try
tty456 14 hours ago [-]
No arm support? Dang
BrandoDev_it 13 hours ago [-]
I'm sorry currently this is more focused to Desktop computers, ARM is not a priority for early beta
tty456 4 hours ago [-]
Np, i'm interested in using this on Raspberry Pi devices. Thanks for the good work!
Rendered at 22:27:54 GMT+0000 (UTC) with Wasmer Edge.
Can you tell us more about the challenges in this area?
0: https://vela-lang.org/
1: https://realm-labs.github.io/vela/overview/