41–50 of 69 posts
Earlier quoted context omitted.
> 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.
This can be easily proven that the extra latency can be noticed by doing a reaction test and recording the screen
Earlier 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.
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.
What 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 archi…
Earlier quoted context omitted.
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.
With Apple’s deprecation of OpenGL on macOS, the author may not have wanted to build on top of something that’s going away.
Earlier quoted context omitted.
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.
The library I’m using used to have a gl backend, but it’s currently unsupported.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
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.
It's probably not as simple as I'm about to make it out to be, but to me, it just seems that positivity is not rewarded nearly as much as negativity. How many people will upvote a Show HN on the new page, opposed to an article about "X is wrong," "X is shutting down," etc.? How many people will upvote a compliment or genuine feedback? "I hate this too" goes a lot farther than "I like this too." Maybe I'm on the wrong…
Earlier 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…
> 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 eff…
Earlier quoted context omitted.
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.
I doubt it’s about Vulkan features and probably has more to do with not wanting to waste time implementing multiple graphics backends. gfx-rs supports both Vulkan and Metal. With Apple’s deprecation of OpenGL on macOS, the author may not have wanted to build on top of something that’s going away.