Anyone else concerned by the decidedly negative cast of the comments? Someone shares something interesting and OP gets a barrage of nit-picky commentary; it's quite discouraging.
Rx v0.3 Released, a modern and minimalist pixel editor in Rust
21–30 of 69 posts
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#22Is such a recent graphics API really necessary? Why isn't a 2D canvas good enough in for this sort of thing?
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 gra…
> 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.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#23What does “modern” mean in this context? I see that word tossed around a lot.
Could mean any number of things in context. In this case it seems to be DPI aware, have some guarantees on memory safety, uses Vulkan/Metal, and targets the current versions of the supported systems natively.
This would be opposed to a legacy codebase that might rely on an old version of OpenGL (which is deprecated completely on MacOS), the OS to scale the window (usually blurring the pixel art), require 32 bit architecture support, and not have any guarantees about memory safety.
As time goes on what features are considered modern will of course continue to change. Most code was modern at one point.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#24Earlier quoted context omitted.
> * 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
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…
> 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.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#25Vulkan support required for a pixel editor? So I can't run this on my X220 despite having a dual-core 2.8Ghz i7 processor, since its integrated GPU is a generation just shy of having Vulkan support. A pixel editor .
It’s one person’s volunteer hobby project, and you’re sarcastically complaining about it using modern hardware features. It’s free software. Go fork it and code up a variant for legacy hardware yourself.
It might be more worthwhile to code up a llvmpipe/swrast variant with Vulkan support, and contribute it to Mesa. That way, legacy hardware will not be cut off from software that expects these "modern" features.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#26Earlier quoted context omitted.
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 gra…
> * 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.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#27Anyone else concerned by the decidedly negative cast of the comments? Someone shares something interesting and OP gets a barrage of nit-picky commentary; it's quite discouraging.
Unfortunately, that's pretty typical of HN nowadays. High up in the HN rules are "Be kind" and "Please don't post shallow dismissals, especially of other people's work," but I don't know that everyone reads the rules or cares much beyond proving they are better than the submitter :/ not sure how the community can get better about this.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#28Earlier quoted context omitted.
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…
> 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.
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.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#29Vulkan support required for a pixel editor? So I can't run this on my X220 despite having a dual-core 2.8Ghz i7 processor, since its integrated GPU is a generation just shy of having Vulkan support. A pixel editor .
It’s one person’s volunteer hobby project, and you’re sarcastically complaining about it using modern hardware features. It’s free software. Go fork it and code up a variant for legacy hardware yourself.
I find it hard to believe this project requires modern hardware features beyond what existing OpenGL versions support.
It would probably be perfectly fine with even OpenGL 2.1, which would then work on every Raspberry Pi out there.
I'm not objecting to supporting hardware acceleration, modern display resolutions somewhat demand it. Just the unnecessary choice of bleeding-edge acceleration API.
Re: Rx v0.3 Released, a modern and minimalist pixel editor in Rust
#30Anyone else concerned by the decidedly negative cast of the comments? Someone shares something interesting and OP gets a barrage of nit-picky commentary; it's quite discouraging.
When you post your project that you've spent hours of hard work on to HN, expect a lot of criticism, with very little of it actually related to the purpose of your work, and even less of it to be actually constructive criticism.