20,741
edits
m (→Replacing PUI: https://sourceforge.net/p/flightgear/mailman/message/37720688/) |
|||
Line 10: | Line 10: | ||
200MB memory is not great, but the bigger problem is the GPU-side memory : 200MB of VRAM is much more ‘valuable’ for textures than for keeping the backing store of hidden dialogs. So I would definitely say use this feature sparingly, until someone adds some C++ logic to destroy the backing texture for hidden canvas windows.<ref>https://sourceforge.net/p/flightgear/mailman/message/37720688/</ref> | 200MB memory is not great, but the bigger problem is the GPU-side memory : 200MB of VRAM is much more ‘valuable’ for textures than for keeping the backing store of hidden dialogs. So I would definitely say use this feature sparingly, until someone adds some C++ logic to destroy the backing texture for hidden canvas windows.<ref>https://sourceforge.net/p/flightgear/mailman/message/37720688/</ref> | ||
For this window behaviour one, I’ve applied it since it’s an opt-in change, but I suspect we may end reviewing this API a little, so I’d suggest not building lots of dialogs across different aircraft, which depend on this behaviour, until we get a bit more experience with it. | |||
So use it, gain some understanding, but maybe we discover in 6 months that it’s a bad idea and have to revert it. (That’s the worst case, but it is kind of a radical change in the lifetime / memory usage of the Canvas, so I just want to mention the worst possibility) I’m 90% sure we can keep this API, so long as we improve the C++ behaviour to release the texture / FBO memory of hidden canvases, which is a reasonable thing to do anyway, it just needs someone to have the time to implement that, and right now, I certainly don’t.<ref>https://sourceforge.net/p/flightgear/mailman/message/37720701/</ref> | |||
=== Replacing PUI === | === Replacing PUI === | ||
{{See also|PUI#Replacement_status}} | {{See also|PUI#Replacement_status}} |