Questions regarding image memory garbage collection

[Weissrolf]

It seems that FGU takes 10 minutes until it does garbage collection for the memory needed to open an image (not display, just open). Is there a reason for this specific time-period?

[Moon Wizard]

This could perhaps be attributed to extensive FoW data for existing tokens on the map which I was discussing in another thread as something we are investigating. Resetting the FoW for all tokens on the map by redragging from combat tracker will force a reset to see if that is the issue.

Also, if you are using any extensions that claim to "preserve" FoW, these extensions are not only dealing with huge data sets, but also inserting file load/save calls into the image opening/closing process which can significantly reduce performance during these actions, especially if running from networked storage. We recommend not using these extensions, due to the overhead they cause.

Regards,
JPG

[Weissrolf]

I was testing opening images with no walls, FoW or any data, no tokens on the image nor combat-tracker. Like before I do these tests with huge images to get a better reading, which then use multiple times the memory of the real image data. 10 minutes later the excessive memory used to load the image is finally unallocated. This extra memory is *not* used/needed by FGU to display the image, but just for opening it for the first time.

The latter brings one disadvantage. During the 10 minutes period the image window can be closed and opened without further CPU/memory load. But if the image window is closed after the extra memory was unallocated then reopening the image takes a longer time and allocates extra memory again.

All that being said, the original issue is with images using so much memory for (only) their initial load to begin with. Keeping the extra memory intact for some time to allow for quick close/open is a good thing, but it shouldn't take 3 times the original image size.

FGU vs. Chrome based VTT displaying a single 121 mp image (12600 px on the longer side) of 346 mb size, all is well here.

Curiously Chrome uses less memory than the image size would suggest, likely because the whole image is loaded as a single texture bitmap into the GPU memory.

FGU's initial memory consumption after loading the image (+10 minutes), peaks at 2000 mb, but drops down to this within seconds. Still about 3 times the image data size (uncompressed 8 bit RGB data).


PS: I am surprised by the 10 minutes period, because I was rather expecting 5 minutes due to the auto-save interval (and then it should be 5 min max, possibly less). I do know that FGU has trouble releasing memory when it is busy doing other stuff while auto-save happens, so maybe the first 5 minute save did not release memory?

[jharp]

This could perhaps be attributed to extensive FoW data for existing tokens on the map which I was discussing in another thread as something we are investigating. Resetting the FoW for all tokens on the map by redragging from combat tracker will force a reset to see if that is the issue.

Also, if you are using any extensions that claim to "preserve" FoW, these extensions are not only dealing with huge data sets, but also inserting file load/save calls into the image opening/closing process which can significantly reduce performance during these actions, especially if running from networked storage. We recommend not using these extensions, due to the overhead they cause.

Regards,
JPG

I do welcome any suggestions for improvements to FoWEnhanced or....here would be the greatest option... actually add the function directly to FG. It certainly would not be difficult given you are the lead programmer and have access to the source. Edit: Or as previously discussed you can also hire me.

Jason

[Moon Wizard]

Can you create a sample campaign with the offending image, and provide it here?

Regards,
JPG

[Weissrolf]

You can try this campaign and images. If you open them one after another you will notice that at first the memory is freed up again right after loading the image. Then at one point you reach an image where it doesn't free up anymore and then maybe the next one is the same. But when you then switch back to the first image all memory frees up immediately again.

It's seems a bit chaotic with these test images. I get more consistent results with larger images (or maybe more content than simple cyan with the 15k ones). But these would have been too large to share here.

The ZIP is compressed using Deflate64 instead of Deflate to make the file size smaller (the forum does not allow to upload 7Z files).

[Moon Wizard]

Just a quick note that all of those images are larger than the suggested resolution of 4Kx4K for images in FG. I'll check in with Carl next week to see if there is anything specific we can do to improve within the constraints of the Unity environment; but opening multiple large images that are anywhere from ~50% (5kx5k) to ~1500% (15kx15k) larger than the recommended sizes is not our primary focus.

Regards,
JPG

[Weissrolf]

Of course they are, they are test case images to emphasize a possible problem and make it reproducible. You surely don't suggest images of pure cyan or 16 million color gradients either?!

Seriously, please come up with your own test-files and quality assurance practices. I don't intend on spending any more time on this than you do yourself.

[jharp]

Weissrolf,

I'll take a look at this given Moon's inability. I'll let you know what I find.

Jason

[Moon Wizard]

Considering that our recommended sizes for images are 4Kx4K, which is what we test with; your comments are completely off base.

Again, I'm asking you to please provide a sample of your existing content which you are saying that you are having problems with, that are under or close to the recommended sizes; along with steps to reproduce. Sending me several extremely large single color examples with no LoS data is not meaningful other than to prove that any system is stressed if you throw enough data at it.

Regards,
JPG