Open Fuzzyzilla opened 7 months ago
I've stopped short because I am not sure how happy I am with this
Might have to sit on it.
I also think this doesn't maybe quite fit what we want for the api, yet at least. If the allocator customization complicates the api too much, letting the user to configure the sizes will also be enough in the short term.
My concern with simply providing sizes is the lack of sharing between user code and the Gui renderer, or between multiple Gui renderers. In my usecase, the texture staging arena will spend all of it's time unused by the Gui except in the first fraction of a second, when it could have been used for any of my app's staging needs.
I am not fully sure how egui 0.24.0 multiwindow functionality works, but if it requires multiple renderers then the ability to share memory between them seems mighty important!
I suppose the sharing between Gui instances could be solved with opaque allocator objects that implement Clone, not far from what's currently in master
, keeping encapsulation. But as I've found here, sharing with the user does complicate things.
First attempt at the custom allocators proposed in #57, including a default implementation providing memory sharing for multi-window apps and a much smaller VRAM allocation footprint (~72MiB combined for
demo_app
).The change was rather intrusive and introduced an
<Alloc>
generic throughout a lot of the code, both library and client side. Not everything is implemented (namely, command buffer + descriptor allocators are not shared nor user configurable, and there is no support for the user callback API so several examples simply fail withnot yet implemented
).I've stopped short because I am not sure how happy I am with this. I think I went too far in making the requirements concrete, to the point that it spills a lot of the implementation details into public view - such as the exact Image/BufferUsage needed for different operations...