> * Today, 4K screens are pretty common, and in the future, 144hz monitors will be more and more popular. If I want to render 2d graphics with no latency in those setups, access to the GPU makes things feasible

are those not feasible today ? due to vsync & al I still have less latency on apps that do software rendering than hardware, even on a 4K 120hz screen

Last time I messed with software rendering I wanted to set the base performance expectation so I blitted the same memory contents to the screen (3840x2160@120) with no sync using OpenGL and got 200-250 FPS on a 2080 Ti/3900X desktop. That means the entirety of my program logic and CPU rendering had to be less than the time it took for the CPU to hand the memory to the GPU to draw or I'd start dropping frames. I'd agree this just isn't realistic anymore going forward from a performance perspective, not to mention the power usage.

I ended up targeting 1920x1080@60 and having a shader nearest neighbor scale that up.

Interesting. Yeah, vsync is a latency killer and it's disabled by default in `rx`. What software renderers are not so good at is drawing lots of pixels every frame, so for example panning a view with lots of images open, or zooming in and out of an image that covers the screen.

I'd expect these kinds of operations to be slow at high resolution without the help of the GPU. You could probably speed things up with SIMD and multi-threading, at the expense of implementation complexity.

> vsync is a latency killer

VSync, if done properly, only adds less than a single frame of latency.

That is 17ms tops for 60Hz, which nobody notices unless you are a pro-gamer on an FPS game. Certainly it does not matter for a pixel editor.

I don’t see how you’d reliably get less than a frame of latency with vsync. If your mouse input lands while you are waiting for the next frame, you will lose at least one whole frame.

In terms of comparison with an FPS, the same amount of responsiveness is required for any UI - ie. there should be no perceptual latency.

Adding 17ms certainly is perceptual.

Text editors on 144 FPS gsync monitor are noticeably better than vsync 60 FPS in a way in which a BMW door is noticeably better at closing than entry level cars. Technically both work the same and yet you can tell they’re very different.

No. VRR (GSync) does not do anything if your computer can achieve 144Hz (which for a text editor any computer should).

maybe i'd agree with you if i hadn't had exactly such monitors attached to my box.

You are seeing the benefits of 144 Hz, not of VRR.

Sounds great until your computer has to do something else for 5 milliseconds.

This can be easily proven that the extra latency can be noticed by doing a reaction test and recording the screen

I haven't said you cannot notice. In fact, I said you can, in the right conditions.

> The popular "classic" 2d libraries like cairo and skia are very big and complicated to build / depend on

It may be harder than editing a Cargo file, but it is something you do once. They are some of the most mature and tested libraries in the world.

> wgpu will eventually also work on the web, so it's a great option for broad platform compatibility

OpenGL works everywhere today, including the web!

> In terms of efficiency (memory, battery, cpu etc.), the modern graphic APIs have more headroom than the GL-based ones

It doesn't matter for a pixel editor. Even if it did, you would have to do a very good job to beat the driver's GL implementation.

Otherwise, you may end up with something slower or buggier!

> Today, 4K screens are pretty common, and in the future, 144hz monitors will be more and more popular. If I want to render 2d graphics with no latency in those setups, access to the GPU makes things feasible

Perhaps, but again, GL allows you to do that.

I don’t disagree that GL would be a fine choice theoretically. I just happen to have a distaste for the OpenGL api. But this was a reply against using something like Cairo as I understood it.

Downvoter: please explain the reason.