9 Comments
Feb 26·edited Feb 28

I was following this article, up until the "Immediate Mode Build, + Cache" section. I feel like there are a few things that I'm missing to be able to understand.

To start off, why would a purely immediate-mode UI_Widget data structure that is rebuilt every frame need to encode a binary tree instead of an array list? Is it so that we can put all UI_Widget instances into a single allocation without having to worry about dynamic sizing? We just... don't need random access to a specific child, since we're rendering every frame? But what about scroll views then, surely we won't want to iterate over thousands of list elements before getting to the place where it actually draws what's on the screen...

Then finally, I think I just got completely lost on the part where we introduce hashing. Why do we have hash_next and hash_prev that are pointers to other UI_Widgets instead of being... hashes? Forgive me for stupid questions because it's the first time I see something like this, I'm very confused.

Edit: turns out UI_Widgets is being used as a node of a doubly linked list that is part of the hashmap, one that's being made from scratch. I'm too used to generic hashmaps in other languages lol

Expand full comment

It may be just my lack of background knowledge, but I failed to understand some things.

So, you store the widgets of the previous frame in a hashmap, which you can access from the current frame's widget. You want to do this because the previous widgets are already calculated so you can know if the user clicked on something or not. Did I get this correct?

For some reason I still don't think I understood how to implement this.

Instead of caching all the widgets of the previous frame, can't you just pass a lambda with the code that would get executed if the user clicked? By the end of the frame, all the computations would be done so the GUI knows if the user clicked, so the lambda gets executed at the end of the frame.

This would be less clean user code but I still don't quite get how to implement the no-lambda version.

Expand full comment

In the layout section, you say that the various steps should iterate through the widget tree in a preorder fashion (top-down). But downward-dependent sizes like `UI_SizeKind_ChildrenSum` seem like they should be computed in a postorder fashion (bottom-up). After all, if any children use downward-dependent sizes as well, I'd want to resolve those first before computing sizes on the parent. Is that an exception to the preorder rule, or am I misunderstanding something?

Expand full comment
May 10, 2022·edited May 11, 2022

Hi Ryan, enjoyed the article. Any chance you could provide a quick sketch of what you mean by "self-correcting exponential animation curves"?

Expand full comment