Gah, please type the names of your projects into the search engine of your choice before polluting everyone's search results with a new project. There are already a few programming projects which go by "rx". I'll boost the one I care about by linking it: http://reactivex.io/
I disagree with the direction of this criticism. Building and shipping is the real victory for anyone with a passion project. To cut them down because of the project name is a cheap critique in my view.
Besides, given the extreme signal:noise ratio of codebases that gain notoriety most projects that share a name or acronym will only have a handful of users even aware of both's existence.
Further with this specific example, "ReactiveX" doesn't even call itself Rx, at least judging by the website. Closest to "Rx" from "ReactiveX" is the different implementations, but they are called RxY where Y seems to be the language. So "RxJS", "RxNet", "RxClojure" and so on. So the name collision doesn't even apply with the mentioned project!
Well, it's a mistake. Due diligence, for any new project, requires searching for existing uses of the intended names and deciding whether they are confusing.
It's difficult because it's easy to miss obscure social niches and name variants, and that's why most people make the task easier with an effort to find unique names.
For example, a sloppy google search for "Rx" yields, in search result order:
- two medical abbreviation, for "recipe" (i.e. "take") in medical prescriptions and for radiography: benign but common and used in proper names of pharmacies, labs etc.;
- Radeon RX-something video cards, unlikely to be confused but likely to yield search result noise for something related to videogames;
- some Lexus cars, popular but more harmless;
- iZotope RX 7, a major software entry: professional "audio repair" DAW plugins from a popular company;
- several unimportant random product and company names, including e.g. some Sony headphones, that collectively prove how "Rx" is an inappropriately short name.
A longer and more unique name would clearly be a better choice. But a further web search for "rx pixel" yields an awful lot of medical video card and car results and a frontal collision on Twitter, where dr. Jennifer Hazel goes by "@Rx_Pixel".
Searching for "rx editor" is also interesting:
- a deluge of iZotope RX results (no hope to become more popular, low-resolution image editors are a smaller niche than audio production)
- the highly popular RxJS JavaScript library. It doesn't take a JavaScript expert to figure out that it's highly popular: the home page mentions a conference about it.
This last conflict should be enough to veto the name "Rx", even without more targeted searches (e.g. social media) and less online-visible usages (e.g. in telecommunications as an abbreviation of receiver or reception, paired with "Tx" for transmitter or transmission).
Did you try search “rx pixel”? Rx is a cool name, and easy to remember. I always have troubles remembering the exact spelling of aseprite and pyxel edit, for example.
There's a very little overlap between the purpose and use case of the two projects. There's not that many good, short names. I personally wouldn't worry about naming conflicts with another project, unless it was a similar project in more than a name.
Many Rust projects are blah-rs where the rs is dropped in the crate name. So it would be normal to be confused and think Rx == RxRust. e.g. https://github.com/rust-lang/futures-rs has crate name "futures".
>There's not that many good, short names.
There'd be loads if the Rust community (or.. the 'rust parliamentary community' (people who actually get involved in the RFC processes and see things through to the end (heroes, imo)) (cf PLP[0])) elected to use namespaces for crates.
Namespaces are a good idea on paper, but you still need to secure the non namespaced name when you reach a bit of popularity or someone else will who will push malware there knowing people will often add a crate by the name they think it has and not necessarily the one it has.
Short names are bad, unless somewhat sheltered from confusion (e.g. brief names of command line tools, which need to be unique only within your PATH environment variable and your installed man pages, not on the web).
Getting a "perfect name" is a lost cause. I named a software project 'minion'. It was perfect, we were top on Google, the only other thing with the name was a font.
Then the movie dispicable me came out, then the Minions movie, and now we are off on page 11.
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
> * 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 and multi-threading, at the expense of implementation complexity.
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.
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.
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.
> 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
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.
Does it support an isometric grid? What about drawing shapes like circles, rectangles? Also curious on what toolkit/library was used for building the UI using rust.
It doesn't, but that would be an interesting feature to develop. Is this something you've used in another editor (iso grid)?
Rust doesn't really have anything super mature in terms of UI, though druid[0] is the one I'm keeping an eye on. Since there's very little "UI" per se in rx, it's currently built directly on top of the graphics layer[1].
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.
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.
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.
Exactly - it’s not that any of Vulkan is needed, it’s that I don’t want to be building on OpenGL when superior graphic interfaces have been available for 5+ years now, and Vulkan+Metal is pretty widely supported on Desktop.
Correct. When I enumerate the other alternatives, there's no single backend that is free from a fatal flaw.
SDL - can it drive 4K displays?
OpenGL - a shattered ecosystem, with some implementations being out of date (Windows) or significantly different (ARM + OpenGL ES)
DX11 - windows only
The only real alternative would seem to be duplicating logic by implementing it for multiple backends.
------
IIUC, the author is using a library that will eventually have OpenGL supported as a backend, so I don't think your predicament is forever, assuming that you actually want to use it and aren't just complaining to complain.
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.
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.
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 site if that's what I'm looking for, but I suggest anyone reading this try to boost some of the more positive comments they see.
I think as humans we are prediposed to attend to negativity rather than positivity. If things are well, we can safely ignore them. If things are not well we need to attend them to potentially fix them or arm ourself with knowledge that will prevent it again.
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.
>Someone shares something interesting and OP gets a barrage of nit-picky commentary
everyone on hn is of the belief about themselves that they're dispassionate (objective) intellectuals and so of course their criticisms aren't in bad faith.
and moderators never address these kinds of comments but do often address comments like yours because they incite "flame wars" (since dispassionate intellectuals can be quite defensive).
I actually saw a comment yesterday from someone meta commenting on someone's project saying that the problem with coders is that they/we are "too nice" and thus we encourage too much bad practice.
So ridiculous that I didn't even feel it deserved a response.
I agree that the tone could certainly be better. That said, feedback like "why does a pixel editor need a graphics accelerator?" is probably warranted, since it limits the end users without apparent good reason. Perhaps just a better way of phrasing?
For working directly with Vulkan, ‘ash’ is preferred. If you want to abstract over platforms, then gfx-rs is solid, or wgpu for a higher level api. Vulkano hasn’t really delivered on its promise unfortunately.
The interaction model is very different, and it's a lot less featureful. I'd say aseprite is a more classic pixel editor, whereas rx is trying something new.
It's OK. Unnecessarily repeated submissions get marked as dupes. But if something like this was on HN previously, it's nice to have a link to previous discussions, for context.
68 comments
[ 0.23 ms ] story [ 124 ms ] threadBesides, given the extreme signal:noise ratio of codebases that gain notoriety most projects that share a name or acronym will only have a handful of users even aware of both's existence.
It's difficult because it's easy to miss obscure social niches and name variants, and that's why most people make the task easier with an effort to find unique names.
For example, a sloppy google search for "Rx" yields, in search result order:
- two medical abbreviation, for "recipe" (i.e. "take") in medical prescriptions and for radiography: benign but common and used in proper names of pharmacies, labs etc.;
- Radeon RX-something video cards, unlikely to be confused but likely to yield search result noise for something related to videogames;
- some Lexus cars, popular but more harmless;
- iZotope RX 7, a major software entry: professional "audio repair" DAW plugins from a popular company;
- several unimportant random product and company names, including e.g. some Sony headphones, that collectively prove how "Rx" is an inappropriately short name.
A longer and more unique name would clearly be a better choice. But a further web search for "rx pixel" yields an awful lot of medical video card and car results and a frontal collision on Twitter, where dr. Jennifer Hazel goes by "@Rx_Pixel".
Searching for "rx editor" is also interesting:
- a deluge of iZotope RX results (no hope to become more popular, low-resolution image editors are a smaller niche than audio production)
- the highly popular RxJS JavaScript library. It doesn't take a JavaScript expert to figure out that it's highly popular: the home page mentions a conference about it.
This last conflict should be enough to veto the name "Rx", even without more targeted searches (e.g. social media) and less online-visible usages (e.g. in telecommunications as an abbreviation of receiver or reception, paired with "Tx" for transmitter or transmission).
Many Rust projects are blah-rs where the rs is dropped in the crate name. So it would be normal to be confused and think Rx == RxRust. e.g. https://github.com/rust-lang/futures-rs has crate name "futures".
>There's not that many good, short names.
There'd be loads if the Rust community (or.. the 'rust parliamentary community' (people who actually get involved in the RFC processes and see things through to the end (heroes, imo)) (cf PLP[0])) elected to use namespaces for crates.
[0] https://en.wikipedia.org/wiki/Parliamentary_Labour_Party
I would also recommend choosing a less overloaded name. Searching for "rx" in Google brings up prescription-related results.
Then the movie dispicable me came out, then the Minions movie, and now we are off on page 11.
* 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
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
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, 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.
I ended up targeting 1920x1080@60 and having a shader nearest neighbor scale that up.
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.
Rust doesn't really have anything super mature in terms of UI, though druid[0] is the one I'm keeping an eye on. Since there's very little "UI" per se in rx, it's currently built directly on top of the graphics layer[1].
[0]: https://github.com/xi-editor/druid
[1]: https://github.com/cloudhead/rgx
[0]:https://marmoset.co/hexels/
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 free software. Go fork it and code up a variant for legacy hardware yourself.
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.
The library I’m using used to have a gl backend, but it’s currently unsupported.
SDL - can it drive 4K displays?
OpenGL - a shattered ecosystem, with some implementations being out of date (Windows) or significantly different (ARM + OpenGL ES)
DX11 - windows only
The only real alternative would seem to be duplicating logic by implementing it for multiple backends.
------
IIUC, the author is using a library that will eventually have OpenGL supported as a backend, so I don't think your predicament is forever, assuming that you actually want to use it and aren't just complaining to complain.
What is this FUD nonsense?
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.
"I hate this too" goes a lot farther than "I like this too."
Maybe I'm on the wrong site if that's what I'm looking for, but I suggest anyone reading this try to boost some of the more positive comments they see.
everyone on hn is of the belief about themselves that they're dispassionate (objective) intellectuals and so of course their criticisms aren't in bad faith.
and moderators never address these kinds of comments but do often address comments like yours because they incite "flame wars" (since dispassionate intellectuals can be quite defensive).
So ridiculous that I didn't even feel it deserved a response.
Is it using MoltenVK?
I'm not super into pixel art, but will definitely be trying this out nonetheless.