Hacker News new | past | comments | ask | show | jobs | submit login
Rx – Extensible pixel editor implemented in Rust, inspired by Vi (cloudhead.io)
349 points by cloudhead 22 days ago | hide | past | web | favorite | 117 comments

Rx has a bit of a "namespace collision" with the functional reactive programming library ReactiveX, which has implementations in many different languages. Often these libraries are called Rx(Java|Swift|Ruby|PHP|js|$LANG).

Paradigm: http://reactivex.io/ Implementations: http://reactivex.io/languages.html

That being said the editor looks very cool! Congrats on shipping!

Apparently there is already one for Rust too. https://github.com/ReactiveX/RxRust

You say "already", but the repo you link to hasn't been updated in nearly five years

Yes. That's how time and tense works.

Another Namespace collision with iZotope RX (a audio retouche tool).

And an even bigger "namespace collision" with it being the common shorthand for medical prescriptions

The editor does look cool. Maybe it should be called rxl rhymes with pixel.

people bring this kind of thing up in every thread as if it's a useful comment for either the reader or the poster (presumably project author). it's almost as common as "this page sucks on mobile".

who cares? we all know how to use Google by now to narrow results by adding qualifying keywords to the query; it's not like I'm just going to search "rx" or even "rx rust" when I'm looking for this project (probably "rx rust pixel"). it's a complete non-issue.

I care. Also it's a potential legal issue for any given project if there's a registered trademark involved.

Plus first result for "rx rust" lead me to https://github.com/ReactiveX/RxRust

> Also it's a potential legal issue for any given project if there's a registered trademark involved.

At some point we will have to generate random strings for the name of our projects because all the "good" (or even "bad") ones are taken. :P

Already a thing: https://namelix.com/app/?keywords=poop+scoop

Highlights for a "poop+scoop" related startup include: Flingo, Trash.ly, Fastpoop, Stinkere, Guunk, and Spoop

I'm surprised it didn't come up with Scoopr.

Let's keep in mind that this is an end user application for pixel artwork. You and I might care that it's Rust. End Users will not. It could be written in Malbolge or BF for all an end user cares about.

Namespace collision is gonna be a pain for end users and newcomers, possibly depressing discovery, which is our point.

Why would you image an author would not care that their page "suck on mobile". If they are posting/sharing their stuff, they more than likely want people to consume (and spread/reshare it). Both being poor experience on mobile and non-discoverably, hard to search for impact that.

i'm sure the author cares. what i'm not sure about is that the author isn't aware and that "hey your site fails on mobile" is of much use to them.

I can easily imagine an author who rarely uses their own mobile page except to make sure that it works at all; or who knows it's not great, but doesn't realize just how annoying it is; or even who has never looked at their site on mobile, ever.

It's a bit puzzling that the GitHub readme has more information about how to use the tool than the website. I don't know what to take away from the single screenshot. Maybe it would be helpful to record an animated GIF or a screencast to demonstrate it in action?

> I don't know what to take away from the single screenshot. Maybe it would be helpful to record an animated GIF or a screencast to demonstrate it in action?


Vi-style editing of pixel art is a new concept that needs to be demonstrated first and foremost to drive this project.

Kakoune is another software for which the uncommon editing paradigm is one of the main features, and it is presented rather well on their main page [0]. A set of animated demonstrations of the editing paradigm comes before a display of the general appearance of the software in realistic contexts.

[0]: https://kakoune.org/

The GH readme file is alot easier to fix than a website. It likely evolves naturally as people open issues to complain that a command doesn't work or that instructions for platform X are missing. The author reads the issues on GH, commits fixes on GH. It's easy to forget the website part.

Pretty much this - I copy stuff over from the README once in a while. I guess the website could benefit from having some of the usage instructions though.

> The GH readme file is alot easier to fix than a website.

With a static site generator, the GH readme file can be the website.

I immediately ctrl+f'd "doc" and was shocked to find no matches. How exactly are "advanced users" supposed to learn the "vi-like" commands?

might still not be ideal but it a bit too hard to make the readme be the website too. Or embed it in the website

I find this very interesting. This is the first time I've seen a developer provide a AppImage for Linux and a build-it-yourself for Mac and Windows. Not sure if the dev owns any computer that runs Windows or Mac, but that seems reasonable. Also is there a reason for using Metal rather than MoltenVK for macOS?

Other than that, great project, spot on license choice, and best of all, Rust!

My main working machine is running Linux - I have access to a Mac, but not Windows.

I've been looking for distrbution mechanisms for a while now, and static binaries are not easy for applications with a GUI.

As for Metal, it just works better currently with the underlying libraries I'm using (GLFW + gfx-rs), than MoltenVK.

For windows, you can create an Azure DevOps account/team for free, and create pipelines against your Github codebase for Windows builds. You'll probably have to install extra pre-requisites for your build though, not sure what's actually in the box, using custom windows agents at work, or linux/docker targets mostly.

It's (Azure DevOps) not always the easiest/best, but it's pretty good... my preference when including the project mgt tools.

> Also is there a reason for using Metal rather than MoltenVK for macOS?

Let me ask it the other way: is there a reason to use MoltenVK if we have a Metal backend?

In OP’s corner case maybe there is, to have a single GPU API and single shader language across all platforms they support.

This doesn’t apply to commercial software. Even if MoltenVK works flawlessly (I don't have experience with the technology), the only GPU API which does on Windows is Direct3D. For cross-platform stuff you want to support multiple GPU APIs, or you’ll have to spend a lot of money supporting users with broken/missing/nonexistent GL/VK drivers.

They do have a single GPU API (wgpu-rs) and only one version of the shaders - SPIRV.

Cross-platform compatibility, and being able to use the same graphics APIs and libraries as the rest of the computer industry.

Unfortunately, today, Vulkan doesn't get you cross platform compatibility. On many Windows machines only dx11/dx12 is available.

gfx-rs (which wgpu-rs is based on) is the closest thing one can get to a low overhead portable GPU API.

> Also is there a reason for using Metal rather than MoltenVK for macOS?

Likely the default of the underlying drawing library for Rust.

In addition, you have to install MoltenVK (a non-trivial task) if you want Vulkan on OS X.

I wonder what the overlap between pixel artists and vi users is.

And perhaps for this overlap a tutorial is not needed, but it would be interesting to me to see it in action.

You would be surprised - I use Godot to make games, program in Vi, and currently do art in Piskel (https://www.piskelapp.com/). Will definitely give RX a try!

Single person game developers who don't want to hire an artist?

Yes - and this is more and more of a common theme.

I guess this only narrows the target audience down further.

I think vast majority of game developers, no matter single or not, use visual studio. Tools like GPU/CPU profilers/debuggers are easier to use when part of the IDE.

> Tools like GPU/CPU profilers/debuggers are easier to use when part of the IDE

Says you. There is reason vim is not "dead" and it's not just cause "old people" still use it. Also, there are plenty of IDEs besides VS.

Finally, "vast majority" doesn't matter for shit with open source. One developer with an itch is enough. If there's a handful of others with same, all the better.

> There is reason vim is not "dead" and it's not just cause "old people" still use it.

Developing videogames is not one of these reasons.

> there are plenty of IDEs besides VS.

How many of these IDEs are supported by mainstream 3D engines, or current-gen console SDKs?

A long available, very well selling commercial add on to many Visual Studio versions was.... Vi emulation mode for the editor.

Similarly, IdeaVim is shown as option in first run dialog of IntelliJ-based editors.

Similarly with Emacs key map in most older IDEs.

I haven't used visual studio since I learned basic in high school.

Modal editing seems like an overlap between the two.


I've been noodling about this concept for several years. I could never quite figure out how to make it efficient, but it's super appealing as a vim user. I'm excited to give this a go!

Great, please send me any feedback you have!

When did everything become extensible instead of extendable. Do they mean different things? Is it a case of while vs whilst?

On a more related note, I find it interesting that the GUI doesn’t appear to be a toolkit like QT, but lower level, like a GUI designed for in-game use.

Only one of these, extensible, was a word at all until the 1940s[0], and extendable is still the less common word.

This is the not-uncommon case where the irregular form is slowly losing ground to the regular form. It's possible that in a century, 'extensible' will be considered archaic.

[0] https://books.google.com/ngrams/graph?content=extendable%2C+...

Wow, that’s fascinating. Thanks for thinking of using google’s ngram tool. I have played around with it a few times but it completely slipped my mind.

> I find it interesting that the GUI doesn’t appear to be a toolkit like QT, but lower level, like a GUI designed for in-game use.

I can't speak for this project, but what you're describing is an Immediate Mode GUI [1]. imgui is one that comes up a lot.

[1] https://en.wikipedia.org/wiki/Immediate_Mode_GUI

Yeah - I don't like the "look" of any of the available GUI toolkits, and I was going for something very minimal in terms of UI, so I decided to build it from scratch.

I am considering using something like stretch[0] to handle layout concerns eventually.

[0]: https://github.com/vislyhq/stretch

I'd be interested to try this but it fails to boot from the app image for me.

  Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)

On Ubuntu using i3 with vulkan drivers installed.

Do other Vulkan samples work for you (e.g. vkcube)? I was getting this issue on a laptop with both NV and Intel. Problem can be worked around by forcing the Vulkan loader to use Nvidia GPU (by providing `VK_ICD_FILENAMES=<path_to_nvidia_icd.json>`).

This is a problem I did not even know I had. Thanks for pointing it out!

would love to see a video of it in action :)

Why would an image editor need Vulkan?

Author here. Rx is actually built on WGPU[0] which will eventually have OpenGL support too. However, I don't really see much of a future for OpenGL - so building a graphics application today - I would pick something like Vulkan over OpenGL, given the choice.

[0]: https://github.com/gfx-rs/wgpu

And to clarify further, the next wgpu-rs version will not have features for backends. Vulkan/Metal/DX12/DX11 will be automatically exposed where appropriate, so there will not be a requirement to have Vulkan.

I think because it uses RGX and that uses Vulcan:


Why wouldn't an image editor need Vulkan? It's gotta render something somehow.

It just seems like an overkill and unnecessary requirement for a pixel editor. The first one I used ran just fine with software rendering on a 25Mhz CPU.

It’s not about power, it’s about portability. As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack.

The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.

> As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack.

Wasn't SDL supposed to be that? What happened to that?

SDL isn’t really simple or low level. You can use it to get an OpenGL context but its built-in 2D stack is very high level (and not very useful for a pixel editor).

I don't understand your comment.

How is Vulkan more portable than a software renderer? And if you need hardware acceleration, OpenGL is more portable than Vulkan.

Today, it seems that Vulkan is really the most portable engine available. OpenGL support has kind of stagnated.

I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like.

Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.

The problem is that vulkan was specifically designed to throw away an amount of portability in favour of allowing lower level access to hardware features. If said hardware features don't exist on a platform, you're stuck. Note the "The Vulkan Portable Subset" having to throw away a number of features to have it work on a number of underlying platforms https://www.khronos.org/vulkan/portability-initiative .

The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.

To chime in: it's not, but a software renderer wouldn't have the desired performance when rendering at the typical resolutions we see today (ie. up to 4K) - or would require a lot of work to get there.

We're talking about a pixel art editor here...

Yeah, it's not a 3d game, but you still have to fill those 4k pixels...

It would seem a bit counterproductive to me to use a software renderer when a graphics API will give you a ton of the desired functionality out of the box, and will have better performance characteristics.

That would only be counterproductive if you actually need that functionality. Very few software would actually need what Vulkan offers. I can only think of AAA games.

What are you talking about? Shader languages are DSLs for working with images. Implementing a software renderer would require re-implementing many, many things you get for free when working with GLSL or HLSL.

Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.

My objection is about Vulkan specifically, not about using the GPU. It makes this software less portable than if they had used OpenGL, and for no benefit that I can see.

I mean, your original comment specifically cited a software renderer, and your original objection was that vulkan was overkill, not that it wasn't well supported, so it seems like you're moving the goalposts all over the place but I'll bite.

As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved.

So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me.

It's a moot point anyway since the developer here is already using a high-level compatibility library.

rx uses wgpu-rs, which primarily supports Vulkan, Metal, and DX12 (though DX11 and GL backends are also partially supported). This is aready relatively portable compared to using GL directly, especially on macOS where it has been deprecated.

> Very few software would actually need what Vulkan offers. I can only think of AAA games.

In about 2005-2007, count of pixels in displays started to grow much faster than CPU power. FullHD monitors entered mainstream market. CPUs stagnated because laptops stopped being expensive toys and started to become desktop replacement.

Nowadays, with 4k or higher rez monitors even in some laptops, pretty much all software actually needs what Vulkan (or D3D, or GL) offers, just to update screen at 60 Hz.

I was specifically talking about Vulkan. You can use the GPU through higher level APIs like OpenGL or D3D11 just fine and those are supported on more hardware than Vulkan.

Only collectively so, when you have both GL and D3D11 backends.

OpenGL is not portable.

Technically it works on Windows, but that’s only true if you’re happy with 11 years old version of the standard, OpenGL 3.0: https://github.com/Const-me/GL3Windows#building-and-running GPUs have changed dramatically over these 11 years, i.e. that version is way too old.

Technically, OpenGL doesn’t work on majority of ARM devices. They use OpenGL ES, not quite the same thing.

Vulkan works on most of these, with the only exception of Windows devices who have Intel GPUs older than Skylake, i.e. older than 2015.

There are a ton of GPUs out there that don't support Vulkan but shouldn't have any trouble running an image editor. By using Vulkan when it doesn't provide much of a benefit for your use-case, you're just artificially limiting your audience.

This project is using wgpu-rs, which already exposes a API that's a bit easier to work with than Vulkan.

wgpu-rs has backends for Vulkan, Metal, DX12, DX11, and GL (partial). The primary backends are the lower-level graphics APIs that are in active development: Vulkan, Metal, and DX12.

It's like using PostgreSQL to save its config. But I don't want to criticize that choice. It looks like the author wrote something that worked for them, and more software should be like that (as counter-intuitive as it sounds).

It's interesting to me that people think of Vulkan as a "heavy dependency", when it's actually the thinnest layer available between an application and the graphics card.

Mac stopped supporting OpenGL.

It also does not support Vulkan.

Apple doesn't, but moltenvk supports vulkan on Mac.

Partially supports Vulkan.

In any case the point stands. A OpenGL wrapper on top of Metal is also possible, no real reason to actually depend on Vulkan for Apple platforms.

> Partially supports Vulkan.

"Partially" is misleading, MoltenVK almost completely supports Vulkan.

At this point the only features not supported are quite minor things, like lack of custom allocator support, and not being able to query pipeline statistics. Geometry shaders are also excluded because they're not implemented in Metal, but they are considered optional in the Vulkan spec.


The real "support" comes with the CTS coverage.

Almost completely is a synonym for partial, otherwise it would be fully supports.

As a professor of mine used to say, 99% there is still not done.

I think it's more the connotation that 'partial' has. In my head that means that there is still significant portions of features missing. Also given the context, partial implies that it is not useful for its intended purpose. I'd say it's not really synonymous for all intents and purposes.

Exactly. For all intents and purposes, you can now target Apple platforms with Vulkan using MoltenVK with a shared codebase. For most people, the fact that custom allocators are ignored would not constitute incomplete coverage of the Vulkan API.

For what it's worth, rx is already targeting multiple native graphics APIs (Vulkan/Metal/etc.) with a shared codebase through wgpu [0], so MoltenVK isn't necessary here anyway.

It might also be interesting to mention that wgpu is implemented with gfx-hal, which provides a common abstraction for native graphics APIs. But besides wgpu, gfx-hal is used in the implementation of gfx-portability [1], which is a MoltenVK alternative that runs on Metal, DX12, and DX11.

[0]: https://github.com/gfx-rs/wgpu

[1]: https://github.com/gfx-rs/portability

This is exactly a kind of project I was looking for to get some inspirations from.


Speaking of Rust and UI, has the story moved beyond "DIY GL / Qt bindings / website backend" or are those still pretty much the options?

Imgui is quite common these days: https://github.com/Gekkio/imgui-rs

Since games are all about graphics check out


Druid has been getting a bunch of attention as well: https://github.com/xi-editor/druid

The gtk bindings are pretty usable at this point.

Interesting but why would you need Vulkan?

Why not? This is a bizzare thing for people to get hung up on.

Because for being such a minimalist editor, it requires something that a lot of hardware out there doesn't have and that often requires proprietary drivers.. even though it doesn't need it.

> often requires proprietary drivers

I think it's just Nvidia and GPUs for ARM SOCs. You need GPU drivers to use desktop anyway.

Yes, also what I thought.

For me it was as simple as installing mesa-vulkan-drivers and re-launching rx. It is a very nice and minimal editor - well done

It doesn't seem to work for vmware with debian, because vulkan is a pain to get working if it's even possible?

Curious about what Rust GUI library they used.

Looks like winit: https://docs.rs/winit/0.20.0-alpha3/winit/

This is based on the cargo manifest: https://github.com/cloudhead/rx/blob/master/Cargo.toml

If you're interested in this space, there's also a lot of effort going into druid: https://github.com/xi-editor/druid

Edit: actually just see this sibling comment: https://news.ycombinator.com/item?id=21115680

None is the answer: the context management (window, input etc.) is done by glfw, but the UI is very minimal and doesn't use any UI toolkit.

How is "implemented in Rust" relevant for anything but bragging rights for using some obscure programming language.

Your software has not more inherent value just because it is written in Rust.

Rust is far from being "an obscure programming language", and I'm pretty sure there are people here on HN that may find useful to browse the source code of a real world application in Rust (and who don't give a shit about the software per se).

Such comment would have made sense if this software was promoted in a more general board/website, but HN audience is mostly compound by developers, so technical aspects matter. On top of that, it also gives an idea about the popularity of a programming language.


Free software lives as long as people keep committing to it. If people want to learn rust they will maybe do so through contributions to free software. You see where this argument us going, language matters.

Given that you have to compile from source for macOS and Windows, knowing that you need to have `rustc` installed is indeed a pre-req.

Why is it featured so heavily, instead of just in the build instructions? I don't know. Marketing? It appears to be by developer(s), for developers, and in the dev space Rust is very vogue right now.

> relevant for anything but bragging rights

Why do you assume bragging rights are not relevant enough?

Languages get mindshare because people see others using them to make stuff. Bragging is essential for growing languages.

People interested in rust but not particularly pixel editors, like several in this thread more interested in the graphics stack/current state of rust gui/graphics than pixel editor itself.

It is relevant for this forum, especially since the project is opensource.

It's a known tactic to get your projects on the HN frontpage.

Yeah, I keep seeing this a lot, I generally don't care that a tool is 'written in X'.

If a tool solves my problem I just use it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact