7 ms·

Rx v0.3 Released, a modern and minimalist pixel editor in Rust

112 points by cloudhead 7y ago

kerkeslager 7y ago
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/ http://reactivex.io/
- liquidise 7y ago
  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.
  - capableweb 7y ago
    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!
  - HelloNurse 7y ago
    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).
    - cloudhead 7y ago
      Yes, except I like this name, and find it fitting, and no one can stop me. We have different priorities :)
    - krychu 7y ago
      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.
- tomashubelbauer 7y ago
  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.
  - fnord123 7y ago
    https://github.com/rxRust/rxRust https://github.com/rxRust/rxRust 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 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 https://en.wikipedia.org/wiki/Parliamentary_Labour_Party
    - tomashubelbauer 7y ago
      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.
      - fnord123 7y ago
        Non namespaced crates can be io.cargo.blah and the short name can be deprecated or even changed programatically.
  - HelloNurse 7y ago
    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).
- thesuperbigfrog 7y ago
  "Rx" already has a history of use as medical shorthand for "prescription". See https://en.wikipedia.org/wiki/Medical_prescription https://en.wikipedia.org/wiki/Medical_prescription I would also recommend choosing a less overloaded name. Searching for "rx" in Google brings up prescription-related results.
- CJefferson 7y ago
  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.
camelCaseCamel 7y ago
Just installed it. Love the project's features and goals. Looking forward to playing with rx more.
- cloudhead 7y ago
  Thanks!
marmaduke 7y ago
Is such a recent graphics API really necessary? Why isn't a 2D canvas good enough in for this sort of thing?
- cloudhead 7y ago
  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
billfruit 7y ago
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.
- cloudhead 7y ago
  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]. [0]: https://github.com/xi-editor/druid https://github.com/xi-editor/druid [1]: https://github.com/cloudhead/rgx https://github.com/cloudhead/rgx
  - billfruit 7y ago
    I think marmoset hexels[0] has an isometric grid, haven't used it myself. I have used the iso(axonometric) grid in Inkscape. [0]:https://marmoset.co/hexels/ https://marmoset.co/hexels/
newnewpdro 7y ago
Vulkan 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.
- jacobolus 7y ago
  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.
  - zozbot234 7y ago
    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.
  - newnewpdro 7y ago
    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.
    - cloudhead 7y ago
      Of course I could have built it with OpenGL. But I really dislike the OpenGL API :) The library I’m using used to have a gl backend, but it’s currently unsupported.
    - wtetzner 7y ago
      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.
JustSomeNobody 7y ago
What does “modern” mean in this context? I see that word tossed around a lot.
- zamadatix 7y ago
  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.
  - cloudhead 7y ago
    Exactly this - “built for the modern world” is another way of saying it.
lordleft 7y ago
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.
- fukuwata 7y ago
  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.
  - thosakwe 7y ago
    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.
    - iovrthoughtthis 7y ago
      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.
- thosakwe 7y ago
  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.
- 7y ago
shmerl 7y ago
> On macOS, Metal support is required. Is it using MoltenVK?
- cloudhead 7y ago
  Nope, uses Metal directly through the gfx-rs backend.
  - shmerl 7y ago
    I see, thanks! What's the preferable approach in Rust, to use Vulkano or gfx-rs (in case you don't need to care about Metal)?
    - cloudhead 7y ago
      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.
sullyj3 7y ago
Anyone know how it compares to Aseprite?
- cloudhead 7y ago
  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.
dang 7y ago
Discussed 3 months ago: https://news.ycombinator.com/item?id=21113796 https://news.ycombinator.com/item?id=21113796
- cloudhead 7y ago
  Are new major releases with new content not okay to be posted?
  - swsieber 7y ago
    It's totally okay. I don't think the link to previous discussions was meant to imply that it's bad to discuss a new release.
  - TeMPOraL 7y ago
    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.
skavi 7y ago
This looks beautiful. I honestly believe more projects should reduce support for older hardware in order to use newer more efficient tech. I'm not super into pixel art, but will definitely be trying this out nonetheless.

112 points by cloudhead 7y ago

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/ http://reactivex.io/

liquidise 7y ago
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.
- capableweb 7y ago
  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!
- HelloNurse 7y ago
  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).
  - cloudhead 7y ago
    Yes, except I like this name, and find it fitting, and no one can stop me. We have different priorities :)
  - krychu 7y ago
    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.
tomashubelbauer 7y ago
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.
- fnord123 7y ago
  https://github.com/rxRust/rxRust https://github.com/rxRust/rxRust 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 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 https://en.wikipedia.org/wiki/Parliamentary_Labour_Party
  - tomashubelbauer 7y ago
    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.
    - fnord123 7y ago
      Non namespaced crates can be io.cargo.blah and the short name can be deprecated or even changed programatically.
- HelloNurse 7y ago
  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).
thesuperbigfrog 7y ago
"Rx" already has a history of use as medical shorthand for "prescription". See https://en.wikipedia.org/wiki/Medical_prescription https://en.wikipedia.org/wiki/Medical_prescription I would also recommend choosing a less overloaded name. Searching for "rx" in Google brings up prescription-related results.
CJefferson 7y ago
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.

camelCaseCamel 7y ago

Just installed it. Love the project's features and goals. Looking forward to playing with rx more.

cloudhead 7y ago
Thanks!

marmaduke 7y ago

Is such a recent graphics API really necessary? Why isn't a 2D canvas good enough in for this sort of thing?

cloudhead 7y ago
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

billfruit 7y ago

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.

cloudhead 7y ago
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]. [0]: https://github.com/xi-editor/druid https://github.com/xi-editor/druid [1]: https://github.com/cloudhead/rgx https://github.com/cloudhead/rgx
- billfruit 7y ago
  I think marmoset hexels[0] has an isometric grid, haven't used it myself. I have used the iso(axonometric) grid in Inkscape. [0]:https://marmoset.co/hexels/ https://marmoset.co/hexels/

newnewpdro 7y ago

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

jacobolus 7y ago
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.
- zozbot234 7y ago
  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.
- newnewpdro 7y ago
  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.
  - cloudhead 7y ago
    Of course I could have built it with OpenGL. But I really dislike the OpenGL API :) The library I’m using used to have a gl backend, but it’s currently unsupported.
  - wtetzner 7y ago
    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.

JustSomeNobody 7y ago

What does “modern” mean in this context? I see that word tossed around a lot.

zamadatix 7y ago
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.
- cloudhead 7y ago
  Exactly this - “built for the modern world” is another way of saying it.

lordleft 7y ago

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.

fukuwata 7y ago
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.
- thosakwe 7y ago
  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.
  - iovrthoughtthis 7y ago
    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.
thosakwe 7y ago
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.
7y ago

shmerl 7y ago

> On macOS, Metal support is required. Is it using MoltenVK?

cloudhead 7y ago
Nope, uses Metal directly through the gfx-rs backend.
- shmerl 7y ago
  I see, thanks! What's the preferable approach in Rust, to use Vulkano or gfx-rs (in case you don't need to care about Metal)?
  - cloudhead 7y ago
    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.

sullyj3 7y ago

Anyone know how it compares to Aseprite?

cloudhead 7y ago
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.

dang 7y ago

Discussed 3 months ago: https://news.ycombinator.com/item?id=21113796 https://news.ycombinator.com/item?id=21113796

cloudhead 7y ago
Are new major releases with new content not okay to be posted?
- swsieber 7y ago
  It's totally okay. I don't think the link to previous discussions was meant to imply that it's bad to discuss a new release.
- TeMPOraL 7y ago
  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.

skavi 7y ago

This looks beautiful. I honestly believe more projects should reduce support for older hardware in order to use newer more efficient tech. I'm not super into pixel art, but will definitely be trying this out nonetheless.