サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
raphlinus.github.io
Note to readers: this is an April Fools post, intended to satirize bad arguments made against Rust. I have mixed feelings about it now, as I think people who understood the context appreciated the humor, but some people were confused. That’s partly because it’s written in a very persuasive style, and I mixed in some good points. For a good discussion of C++ safety in particular, see JF Bastien’s t
A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question. Generally the top contenders are egui, Iced, and Druid, with Slint looking promising as well, but web-based approaches such as Tauri are also gaining some momentum, and of course there’s always the temptati
Rust is an appealing language for building user interfaces for a variety of reasons, especially the promise of delivering both performance and safety. However, finding a good architecture is challenging. Architectures that work well in other languages generally don’t adapt well to Rust, mostly because they rely on shared mutable state and that is not idiomatic Rust, to put it mildly. It is sometim
Why (and when) a perceptual color space? Most image processing is done using a device color space (most often sRGB), and most libraries and interfaces expose that color space. Even when an image editing tool or a standard (such as CSS) exposes other color spaces, it’s still most common to use the device color space. But for some use cases, a perceptual color space can give better results. Basicall
This is a followup to my previous post on the stack monoid, but is intended to be self-contained. Motivation: tree structured data GPUs are well known for being efficient on array-structured data, where it is possible to operate on the elements of the array in parallel. That last restriction doesn’t mean that the operations have to be completely independent; it’s also well known that GPUs are good
This is a response to the Rust call for blogs 2021 and also a followup to last year’s entry. It will be entirely focused on GUI. There is considerable interest in GUI toolkits for Rust. As one data point, it was the 6th highest rated challenge for adoption in the 2019 Rust survey, just behind async I/O. There is also a fair amount of activity towards this goal, though as a community it still feels
Update 7 May 2022: A followup to this post containing significant conceptual advance is Xilem: an architecture for UI in Rust. I consider the Crochet experiment to be mostly negative, as there were a number of ergonomic and functional “paper cuts,” though several of the research goals were met, at least to some extent. This is a followup to my post about a year ago, Towards a unified theory of rea
A bit more than four years ago I started the xi-editor project. Now I have placed it on the back burner (though there is still some activity from the open source community). The original goal was to deliver a very high quality editing experience. To this end, the project spent a rather large number of “novelty points”: Rust as the implementation language for the core. A rope data structure for tex
Update 26 Sep 2020: A followup to this post is Towards principled reactive UI. Update 7 May 2022: A followup to this post containing significant conceptual advance is Xilem: an architecture for UI in Rust. In trying to figure out the best reactive structure for druid, as well as how to communicate that to the world, I’ve been studying a wide range of reactive UI systems. I’ve found an incredible d
In response to the call for blogs about the vision for Rust for 2020, I’m going to write about GUI. I believe the time is right for a native GUI toolkit written in Rust, and that such a thing would fill a very important niche. There is a demand for performance (which, to me, includes startup time, RAM footprint, and binary size), and Rust is in the best position to deliver on that. I’ve been inter
I’m about to accept a PR that will increase druid’s compile time about 3x and its executable size almost 2x. In this case, I think the tradeoff is worth it (without localization, a GUI toolkit is strictly a toy), but the bloat makes me unhappy and I think there is room for improvement in the Rust ecosystem. Should we care? For me, bloat in Rust is mostly about compile times and executable size. Co
SIMD is a powerful performance technique, and is especially valuable in signal and image processing applications. I will be using it very extensively in my synthesizer, and also it’s increasingly used in xi-editor to optimize string comparisons and similar primitives. Traditionally, programming SIMD has been very difficult, for a variety of reasons. Until recently, the most practical approach was
For a fun project, I’ve been tinkering with xi-win, an experimental Windows front-end for xi-editor, written in Rust. I’m basically optimizing for performance, so making a number of somewhat unusual decisions. Among other things, I’m writing the UI myself, rather than using an existing toolkit or framework. Code for this post: xi-win/xi-win-ui. If you’re on a Windows machine, try the calc example!
このページを最初にブックマークしてみませんか?
『Raph Levien’s blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く