Rx v0.3 Released, a modern and minimalist pixel editor in Rust | Hacker News Reader

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

rx.cloudhead.io

112 pointscloudhead66 comments

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

Thanks!

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

[0]: https://github.com/xi-editor/druid

[1]: https://github.com/cloudhead/rgx

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/

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

Are new major releases with new content not okay to be posted?

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.

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.

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

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

No. VRR (GSync) does not do anything if your computer can achieve 144Hz (which for a text editor any computer should).

Sounds great until your computer has to do something else for 5 milliseconds.

maybe i'd agree with you if i hadn't had exactly such monitors attached to my box.

You are seeing the benefits of 144 Hz, not of VRR.

This can be easily proven that the extra latency can be noticed by doing a reaction test and recording the screen

I haven't said you cannot notice. In fact, I said you can, in the right conditions.

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.

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

Perhaps, but again, GL allows you to do that.

Downvoter: please explain the reason.

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.

> On macOS, Metal support is required.

Is it using MoltenVK?

Nope, uses Metal directly through the gfx-rs backend.

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)?

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.

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

Exactly this - “built for the modern world” is another way of saying it.

Anyone know how it compares to Aseprite?

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.

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?

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.

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

Yes, except I like this name, and find it fitting, and no one can stop me. We have different priorities :)

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.

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

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.

Non namespaced crates can be io.cargo.blah and the short name can be deprecated or even changed programatically.

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

Absolutely. And even ls, sed, etc are in the coreutils package. Not 'ls' package.

"Rx" already has a history of use as medical shorthand for "prescription". See 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.

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.

Reply on news.ycombinator.com