Immediate-Mode-UI / Immediate-Mode-UI/Nuklear
Question about different commands, sizes, and buffer alignment
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 11.4k
- Forks
- 686
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 3
Description
I'm not an expert, so my thoughts may be flawed here.
Some investigation that I have done has left me a little bit confused.
At the end of the draw pipeline, nuclear starts to push different primative draw commands into a continuous buffer stored in the CTX. Each new command gets tacked onto the end except in the case of a popup which gets stitched in at the `nk_end` call.
Within all of these pushes and buffer writing and pointer movement, there is a lot of math being done for memory alignment of the commands in the buffer. This isn't necessarily a bad thing (it's functional today). But I find it rather confusing. If I were to rewrite this, I would consider making a command type as a union of all command type to be pushed, that way alignment is lnt really something that anyone needs to consider. Every command would be the same size.
That, or perhaps I would try a linked list setup similar to how the Amiga RTOS handled its tasks.
@RobLoach
I'm just genuinely curious about the design decision here. And wondering what the teams thoughts on playing around with that structure are.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The discussion refers to the draw pipeline, the continuous command buffer in the CTX, and popup insertion at nk_end, but names no file or test. Start by tracing those entry points and the alignment calculations; the issue does not define a concrete change or acceptance criteria for determining when the work is done.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100