Kruci: Post-mortem of a UI library
1–10 of 15 posts
Re: Kruci: Post-mortem of a UI library
#2Very interesting thought process, with lots of nitty gritty details. I recently had some idea around a repetitive process at work, and decided to try it in TUI. Oh what a ride it was!
Even armed with a library like charms or bubbletea in Golang, sometimes its just amazing how all the internals "clicked" together, to render layouts and widgets.
Re: Kruci: Post-mortem of a UI library
#3> but that, in turn, means that you have to lock that RwLock every frame, also not great.
Unless that RwLock is in contention to get acquired every frame I doubt it will add anything significant to the frame time. Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust.
Furthermore- UI updates are usually all run from the same single thread, so it’s unlikely the other widgets could even contend for that lock! You might be able to get away with the lock approach and you may even be able to use Rc>, which would get a little speed up.
Re: Kruci: Post-mortem of a UI library
#4> but that, in turn, means that you have to lock that RwLock every frame, also not great. Unless that RwLock is in contention to get acquired every frame I doubt it will add anything significant to the frame time. Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust. Furthermore- UI updates are usually all run from the same single thread, so it…
> Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust.
:+1: - it was mostly about "damn, it _feels_ like there should be a better way".
> You might be able to get away with the lock approach and you may even be able to use Rc>, which would get a little speed up.
In this particular case that'd be a bit more awkward, because in the actual game the UI is driven by async fn (the rendering itself is sync, of course, but waiting for input is async, and both happen as a part of the same function).
`spawn_local()` could be a good enough solution for that, though.
Re: Kruci: Post-mortem of a UI library
#5I appreciate the name, a niche Polish Internet culture meme
Re: Kruci: Post-mortem of a UI library
#6> but that, in turn, means that you have to lock that RwLock every frame, also not great. Unless that RwLock is in contention to get acquired every frame I doubt it will add anything significant to the frame time. Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust. Furthermore- UI updates are usually all run from the same single thread, so it…
Yes, virtually all locks (any language) are free if they don't have contention.
Re: Kruci: Post-mortem of a UI library
#7I appreciate the name, a niche Polish Internet culture meme
Last place I would expect to find klocuch reference
Re: Kruci: Post-mortem of a UI library
#8What monospace font is this? Really good
Re: Kruci: Post-mortem of a UI library
#9What monospace font is this? Really good
Code blocks use Iosevka (slightly configured - https://codeberg.org/pwy/website/src/commit/721438bc7d14789c...).
Screenshots use Berkeley Mono (my "daily driver" font).
Re: Kruci: Post-mortem of a UI library
#10> but that, in turn, means that you have to lock that RwLock every frame, also not great. Unless that RwLock is in contention to get acquired every frame I doubt it will add anything significant to the frame time. Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust. Furthermore- UI updates are usually all run from the same single thread, so it…
> Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust. :+1: - it was mostly about "damn, it _feels_ like there should be a better way". > You might be able to get away with the lock approach and you may even be able to use Rc >, which would get a little speed up. In this particular case that'd be a bit more awkward, because in the actual game…
> it _feels_ like there should be a better way
Yeah, totally. I have those same feelings. It's hard to fight it because `.lock()` and friends do _feel_ heavy!