Retaining state is a pain and causes bugs. Trying to get fancy a la react and diffing the tree for changes makes not sense. That was a performance hack because changing the DOM in JS used to be slow as hell. You don't need that.
Just redraw the whole thing every frame. Great performance, simple, less bugs.
I actually use a very similar paradigm successfully in a game [1] whose (immediate-mode) UI is fully responsive. I allow more operations than just cutting to do that, but the basic idea seems to be the same. The code may look like a bit of a mess at a first glance [2], but I still find it easier to work with and make it do what I actually want with some very basic vector maths, than with the layout-container rules of most UI frameworks.
At what point do you think you’d give in and use an existing solution?
I’m going through similar “hell” (my words). I just wanted some simple Ui for WebXR but the dipshits that designed XR for the web fucking threw all the web parts out so you can not just put up a few simple html elements up in XR. You have to write your own UI library from scratch. It’s so mind bogglingly stupid.
In any case, having to write it, like you I started small and the it quickly ballooned because even simple things get complicated quickly, all the while I’m cursing under my breath there is a perfectly unable system but TPTB chose not to offer it >:(
existing solutions for my specific use case were limited, i intentionally wanted something barebones so that I could hack at the raw surfaces / display buffers to cut corners for performance. one part learning experience, one part stubbornness.
WebXR sounds like a different beast entirely. do you have to write your own rendering backend in WebGL for that?
Immediate mode GUI is the way to go.
Retaining state is a pain and causes bugs. Trying to get fancy a la react and diffing the tree for changes makes not sense. That was a performance hack because changing the DOM in JS used to be slow as hell. You don't need that.
Just redraw the whole thing every frame. Great performance, simple, less bugs.
> While it’s far from perfect, writing it taught me more about UI systems than I ever would have learned by sticking to established solutions alone.
This is a great attitude to have. Keep up the great work.
rectcut is a good API for layout if you have a fixed viewport (eg eink display)
the API is a very simple one where you slice parts off an initial Rect. the only feature it provides is that it tracks (x, y, h, w) for you.
it doesn't work well with intrinsic sizes - it's more of a top down, fixed size thing.
I actually use a very similar paradigm successfully in a game [1] whose (immediate-mode) UI is fully responsive. I allow more operations than just cutting to do that, but the basic idea seems to be the same. The code may look like a bit of a mess at a first glance [2], but I still find it easier to work with and make it do what I actually want with some very basic vector maths, than with the layout-container rules of most UI frameworks.
[1]: https://fruitsandtails.fghj.cz/
[2]: https://codeberg.org/spiffyk/FruitsAndTails/src/branch/main/...
author here - thanks for posting :D would love to hear any thoughts or questions.
At what point do you think you’d give in and use an existing solution?
I’m going through similar “hell” (my words). I just wanted some simple Ui for WebXR but the dipshits that designed XR for the web fucking threw all the web parts out so you can not just put up a few simple html elements up in XR. You have to write your own UI library from scratch. It’s so mind bogglingly stupid.
In any case, having to write it, like you I started small and the it quickly ballooned because even simple things get complicated quickly, all the while I’m cursing under my breath there is a perfectly unable system but TPTB chose not to offer it >:(
existing solutions for my specific use case were limited, i intentionally wanted something barebones so that I could hack at the raw surfaces / display buffers to cut corners for performance. one part learning experience, one part stubbornness.
WebXR sounds like a different beast entirely. do you have to write your own rendering backend in WebGL for that?
1 reply →