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.

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

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.

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.

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.

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

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.

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

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

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.

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

Thanks!

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

The author correctly states that BFT algorithms are meant to handle arbitrary failures, but then explains how that is the wrong choice because one shouldn't handle malicious actors at the consensus level. Yet there are categories of faults that cannot be handled by basic FT systems, that BFT systems can handle, and are not due to malice. So all in all, BFT is the right choice.

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

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.

Great, please send me any feedback you have!

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

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.

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

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.

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.

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

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.

Not a blockchain.

Monadic | (Senior) Software Engineer | Berlin | Remote OK | Full time | http://monadic.xyz

We're hiring a couple of experienced protocol & backend engineers who <3 free software, to work on a decentralized code collaboration and incentivization platform for FOSS. We work mainly in rust and haskell, are remote friendly and based in Berlin. Salary is flat and generous for the EU. Send me an e-mail at alexis@monadic.xyz with your CV or open-source work if interested!

They may seem, but they aren't so far, is the reason. There's major problems with that family of sybil resistance systems that have yet to be solved in practice.

Nice, but it misses the point that `IO` is actually pure (referentially transparent) in Haskell:

  let x = putStrLn "hello"
  in do x ; x

is equivalent to:

  do putStrLn "hello" ; putStrLn "hello"

Monadic | Software Engineer | Berlin | Remote OK | Full time | http://monadic.xyz

We're looking to hire a few senior software engineers with functional programming experience in the next couple of months to work on peer-to-peer and blockchain technology. Salary is EUR 100K across the board. We're a team of 15, based in Berlin. Drop me an email if interested: alexis (at) monadic.xyz.

Thanks

If you’re not interested in how things work under the hood, there are nice high level docs for you here http://radicle.xyz/docs/index.html :)