nicbarker
Add Id field into the CustomElementConfig to simplify tagging of the typeless data ptr.
I have been handling a few different custom commands and didn't like having to create a type and data wrapper before passing it into the custom data.
Since in most cases a numerical based ID will be used to differentiate between render handlers of the passed in data I added an extra field to account for that by default to simplify construction of custom elements.
ToDo:
- [ ] Modify CustomRenderingCommands example to demo the purpose of the change.
Why not cast your numeric ID to void*? Or make a simple static array of IDs and reuse pointers to them?
Why not cast your numeric ID to
void*? Or make a simple static array of IDs and reuse pointers to them?
Well the issue isn't particularly the id's but rather the bundling of the data with that id. Even if the ID's are pointers, I still need to bundle SpecificRenderData and the ID for how to handle that data and then pass an address to it into the customElementData.
ID's are the simplest way to define the appropriate handling for the passed in void* data, which is going to be the case for most people using custom render commands it felt like the most elegant solution to add the id field directly.
Hopefully I didn't misunderstand what you were asking :)
Hmm, rather I was the one who misunderstood what you were suggesting. Sounds like you have custom elements which only require a single pointer to existing data (not a render-specific struct like Clay's RenderData?) In which case I agree, it does sound annoying to bother allocating/managing a bunch of tiny wrapper structs.
Note that elements have also a .userData field. I'm using the .customData field to specify the type of custom element, and then put in .userData relevant rendering information.
Note that elements have also a
.userDatafield. I'm using the.customDatafield to specify the type of custom element, and then put in.userDatarelevant rendering information.
The issue isn't that there isn't a way to pass the data I want through; I just don't like the idea of passing non-pointer data through a pointer. I know I could create some globals and pass those as the "Id" values, but that just feels way tooo tacky to me. But that is a good idea you suggest.