3 ms·

It's not strictly necessary, I chose wgpu for a few reasons: * Its backend (gfx-rs) is one of the most mature rust libraries for doing graphics * The popular

It's not strictly necessary, I chose wgpu for a few reasons: * Its backend (gfx-rs) is one of the most mature rust libraries for doing graphics * The popular "classic" 2d libraries like cairo and skia are very big and complicated to build / depend on * wgpu will eventually also work on the web, so it's a great option for broad platform compatibility * In terms of efficiency (memory, battery, cpu etc.), the modern graphic APIs have more headroom than the GL-based ones * 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

jcelerier 7y ago
> * 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
- cloudhead 7y ago
  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.
  - gdxhyrd 7y ago
    > 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.
    - baq 7y ago
      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.
      - gdxhyrd 7y ago
        No. VRR (GSync) does not do anything if your computer can achieve 144Hz (which for a text editor any computer should).
        zamadatix 7y ago
        Sounds great until your computer has to do something else for 5 milliseconds.
        baq 7y ago
        maybe i'd agree with you if i hadn't had exactly such monitors attached to my box.
        gdxhyrd 7y ago
        You are seeing the benefits of 144 Hz, not of VRR.
    - xchaotic 7y ago
      This can be easily proven that the extra latency can be noticed by doing a reaction test and recording the screen
      - gdxhyrd 7y ago
        I haven't said you cannot notice. In fact, I said you can, in the right conditions.
    - cloudhead 7y ago
      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.
- zamadatix 7y ago
  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.
gdxhyrd 7y ago
> 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.
- gdxhyrd 7y ago
  Downvoter: please explain the reason.
  - deleted 7y ago
    [deleted]
- cloudhead 7y ago
  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.

jcelerier 7y ago

> * 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

cloudhead 7y ago
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.
- gdxhyrd 7y ago
  > 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.
  - baq 7y ago
    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.
    - gdxhyrd 7y ago
      No. VRR (GSync) does not do anything if your computer can achieve 144Hz (which for a text editor any computer should).
      - zamadatix 7y ago
        Sounds great until your computer has to do something else for 5 milliseconds.
      - baq 7y ago
        maybe i'd agree with you if i hadn't had exactly such monitors attached to my box.
        gdxhyrd 7y ago
        You are seeing the benefits of 144 Hz, not of VRR.
  - xchaotic 7y ago
    This can be easily proven that the extra latency can be noticed by doing a reaction test and recording the screen
    - gdxhyrd 7y ago
      I haven't said you cannot notice. In fact, I said you can, in the right conditions.
  - cloudhead 7y ago
    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.
zamadatix 7y ago
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.

gdxhyrd 7y ago

> 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.

gdxhyrd 7y ago
Downvoter: please explain the reason.
- deleted 7y ago
  [deleted]
cloudhead 7y ago
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.