Quote:
Originally Posted by random_id
My T-Chain plugin loads various plugin modules, each with different assets (due to 3d lighting). The current size of all of my pngs are around 30MB, but I am continuing to add more. The compiled binaries are about 30MB for VST/VST3, and about 100MB for AAX. Most of my other plugins are about 1/8th the size. The installers for T-Chain are up to 350MB, with all compression options turned on.
I would like to reduce the installer size. I guess I could start splitting up the installers by 32 and 64 bit versions, and/or plugin formats. My long-term concern would be if I continue to add assets, at what point does it become a problem within the DAW. I guess it makes more sense to share the assets in RAM than have each plugin instance consume more memory for bitmaps. That could get ugly.
|
I don't see much problem adding 3-4mb more RAM usage per plugin for your regular one. If you look it other way around, T-Chain is heavy plugin with a lot of modules and naturally people could expect higher RAM usage, also you can add to memory only bitmaps that are being used, so that could limit RAM a lot I think.
As for benefits, you can basically reduce installer to 50-100mb by loading bitmaps from run time.
if we don't share RAM we can also expect huge performance benefits when scaling like 5x-15x faster and that would be extremely helpful if you have a lot of bitmaps to scale like in T-Chain. Also, current implementation of scaling is fundamentally flawed since if you have two plugin interfaces open at the same time and you scale graphics in one bitmaps will be scaled for second plugin too, so the workaround is to blackout the screen in second plugin instance and to request interface reopening...
I have not worked yet with the cairo and the bitmaps so it might be possible that cairo automatically shares RAM for same bitmaps, but we will see. Also there is an option to scale bitmaps at every redraw, but I guess cairo would cache that automatically.