
Rx v0.3 Released, a modern and minimalist pixel editor in Rust - cloudhead
https://rx.cloudhead.io
======
camelCaseCamel
Just installed it. Love the project's features and goals. Looking forward to
playing with rx more.

~~~
cloudhead
Thanks!

------
billfruit
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
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
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/)

------
dang
Discussed 3 months ago:
[https://news.ycombinator.com/item?id=21113796](https://news.ycombinator.com/item?id=21113796)

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

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

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

~~~
cloudhead
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
> * 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
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
> 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.

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

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

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

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

------
shmerl
_> On macOS, Metal support is required._

Is it using MoltenVK?

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

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

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

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

------
sullyj3
Anyone know how it compares to Aseprite?

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

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

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

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

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

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

~~~
HelloNurse
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
Yes, except I like this name, and find it fitting, and no one can stop me. We
have different priorities :)

