Questions regarding image memory garbage collection [Archive]

Moon Wizard

January 28th, 2022, 21:40

Weissrolf

January 28th, 2022, 22:38

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.
https://i.imgur.com/C0uiuGz.png
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).
https://i.imgur.com/oH2ppGZ.png

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

January 28th, 2022, 22:44

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

January 28th, 2022, 22:50

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

Regards,
JPG

Weissrolf

February 3rd, 2022, 22:48

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

February 4th, 2022, 21:52

Weissrolf

February 4th, 2022, 23:12

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

February 4th, 2022, 23:12

Weissrolf,

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

Jason

Moon Wizard

February 4th, 2022, 23:23

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

Weissrolf

February 4th, 2022, 23:23

On a side-note: Various Patreon based mapmakers are offering 200 dpi versions of their maps, which are regularly sized larger than 4k and browsers have zero problems opening them in less than a second on my computer. FGU being 64-bit sure should be able to handle this.

Weissrolf

February 4th, 2022, 23:24

You win, I don't care. Be well.

MrDDT

February 4th, 2022, 23:28

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

Just to put this in perspective, using only a 4k x 4k map is less than 2x larger than FGC, which one of the major selling points of FGU over FGC was the very very limited map sizes we could do at 2048 x 2048 FGC.

This also means that any battle map couldn't even take into account any ranged combat with bows whatsoever. This is a major selling point of FGU was that it was on 64 bit code so we could use much larger maps. Now you telling us that we are limited to this size of a map or we going to have memory issues locking up the system and causing massive issues?

I don't mind when you guys are saying we are working on things and it can take some time to work things out, but if you telling us we are limited to a 4k x 4k pixel map else we going to have issues, this suggests to me majorly that I need to look for another VTT.

Even using the largest map here you are talking about, 15k x 15k (which is a good sized map) that size is only about 28MB jpg map. (Give or take)
This is not a large file. Many images are much larger than this. Using the normal DPI of 72, it would be about 200 x 200 map, which is a pretty good size but it's not crazy to think to use for an outdoor map where ranged combat is likely to happen.

The suggestion that we should limit our maps to less than 2MB is pretty silly. It really just doesn't happen unless we force it to happen. Using really low DPI.

Weissrolf

February 4th, 2022, 23:37

To be fair, a 15k x 15k map is 644 mb in memory size, regardless of the JPEG filesize. Usually opening such an image from a JPEG uses about 2.5 to 3 times as much memory in various programs to *open* the file, which then can be released right afterwards. The latter is something that FGU can fail at (or rather take the 10 minutes as described in the OP). PNG and TIF versions usually don't need much more memory than the image size, but the file-size is much larger to begin with.

Here is opening and then displaying a 15k JPEG in Chrome.

Opening:
https://i.imgur.com/tuEQipZ.png

Viewing:
https://i.imgur.com/ozCBwpv.png

Notice how it takes less memory to view the image than the actual image size once it's loaded and memory is released. Likely because the whole image is fully loaded into GPU memory as a single tile (16k px max on most modern GPUs). Could also be that Chrome divides the image into smaller tiles and then only uses memory for the currently displayed resolution (2k for my display).

FGC was able to load/display large images as long as the total memory consumption stayed below about 2 gb. A 19k x 25k px image is about 1.4 gb large and since FGC was able to load TIFF files I could load that in a short test, as far as I remember.

Anyway, you figure this out or not. I did my share.

damned

February 5th, 2022, 00:51

Just to put this in perspective, using only a 4k x 4k map is less than 2x larger than FGC, which one of the major selling points of FGU over FGC was the very very limited map sizes we could do at 2048 x 2048 FGC.

...

Even using the largest map here you are talking about, 15k x 15k (which is a good sized map) that size is only about 28MB jpg map. (Give or take)
This is not a large file. Many images are much larger than this. Using the normal DPI of 72, it would be about 200 x 200 map, which is a pretty good size but it's not crazy to think to use for an outdoor map where ranged combat is likely to happen.

The suggestion that we should limit our maps to less than 2MB is pretty silly. It really just doesn't happen unless we force it to happen. Using really low DPI.

a 4k x 4k map is 4x larger than a 2k x 2k map.
a 15k x 15k map is 56x larger than a 2k x 2k map.

I dont see where it recommends a maximum of 2MB.

You can use maps of any size. The bigger the map and the more line of sight points it contains and the more lights it contains the more resources it requires. If you find that the maps that you are using are causing performance issues then you need to adjust them down.

GunnarGreybeard

February 5th, 2022, 01:04

I think maybe the 2MB references are a holdover from the 'recommendations' for FGC?? I know the Adventure Module Creation Best Practices guide, originally written for FGC suggested 1MB which FGU should handle easily.

MrDDT

February 5th, 2022, 01:05

a 4k x 4k map is 4x larger than a 2k x 2k map.
a 15k x 15k map is 56x larger than a 2k x 2k map.

I dont see where it recommends a maximum of 2MB.

You can use maps of any size. The bigger the map and the more line of sight points it contains and the more lights it contains the more resources it requires. If you find that the maps that you are using are causing performance issues then you need to adjust them down.

You right it is 4x (almost) than a 2048x2048 map, however, its less than 2x when you consider the distance a mob can be away from someone using a bow. Thus I was talking about ranging for bows/ranged weapons. I'm looking at it practically.

2MB is about the size of a 4kx4k map compressed in standard jpg format.

I figured this is the case, however, when you guys are putting out "recommended" size is baring bigger than a super super small size of old FGC maps there are problems as this is was supposed to be so much better. This is just the slope you start to slide us off when we say "this isn't working right", "well you using too big of a map! you need to use this really small sized map and everything works fine".

Just as it would be when you all start telling us to turn off all exts and the game works fine. Well it was sold to us as having ext options. If we can't use ext else the game runs like crap what is the point of this VTT? If we can't use maps that are normal sized of what map makers put out, what is the point of using this VTT.

I'm upset if this is really the stance that 4kx4k is the size we should be using else we will see crap performance.

Now I figured off the get go that LOS is really the issue, because I've used 50kx50k maps already with zero issues. So I know this is really not the case in FGU. Maybe the case when you push the limits and start opening up 20 of these images in game and expect it to run without issue.
The major issue mostly that I've seen running a large map like that is upload speed/delay waiting for players to download a 350MB map, and ram usage but once it's loaded, its not bad. Just don't put an LOS on it else the game will be crap.

Just FYI, larger maps does not = more LOS points, just more likely to have more LOS points.

I just think that if this is the stance of 4kx4k images are "recommended" then why was this put into FGU in the first place, this is such old tech being pushed as new then?

I think the LOS issues and maybe even FOW/Lighting are the real issues here but if this is the stance of SW then it is what it is, we all have to major our own choices.

I'm done with this topic/thread as it's just going to end up getting locked down with no real reason given.

jharp

February 5th, 2022, 03:24

You right it is 4x (almost) than a 2048x2048 map, however, its less than 2x when you consider the distance a mob can be away from someone using a bow. Thus I was talking about ranging for bows/ranged weapons. I'm looking at it practically.

...

I'm done with this topic/thread as it's just going to end up getting locked down with no real reason given.

I'm sure the real issue comes down to money. SW either doesn't have or doesn't want to spend the money required to bring forward the real potential. I suspect they will simply continue to limp along until another PC based VTT comes along. There is no reason that this engine cannot handle the number of LoS points of almost any map given that such engines are designed for such work. Look at any AAA FPS and tell me that the LoS work done in FGU is not considerably less.

They need to get the expertise to make this work or just admit defeat. I don't see the love increasing for SW, only decreasing.

Jason

Weissrolf

February 5th, 2022, 10:06

I think the LOS issues and maybe even FOW/Lighting are the real issues here but if this is the stance of SW then it is what it is, we all have to major our own choices.
From SW's point of view, maybe. From my point of view FGU is haunted by memory issues. In case of large images - not even maps with LOS or anything on it - these are very reproducible, but as we just learned SW doesn't care for maps larger than 4k. So no wonder we don't get any acknowledgement of this.

The latter is a problem also, because sometimes we do get improvements, but without knowing. I was quite surprised that some of the images I used for testing did indeed get memory released immediately after loading/opening. I think this is improved over what I experienced months ago. But frankly, I don't really know, because the issue was never acknowledged and we don't get any easily accessible changelogs when FGU does it updates.

Same with 3D rolling randomness. It improved manyfold since my tests at the beginning of December 2020, but we don't know why it improved and by what update. My *guess* is that a change to the 3D dice engine did that at the end of Dec 2020 which officially was meant for "better optics".

No acknowledgement of issues + lack of in-application changelogs = no idea what's happening.

Jiminimonka

February 5th, 2022, 10:54

From SW's point of view, maybe. From my point of view FGU is haunted by memory issues. In case of large images - not even maps with LOS or anything on it - these are very reproducible, but as we just learned SW doesn't care for maps larger than 4k. So no wonder we don't get any acknowledgement of this.

The latter is a problem also, because sometimes we do get improvements, but without knowing. I was quite surprised that some of the images I used for testing did indeed get memory released immediately after loading/opening. I think this is improved over what I experienced months ago. But frankly, I don't really know, because the issue was never acknowledged and we don't get any easily accessible changelogs when FGU does it updates.

Same with 3D rolling randomness. It improved manyfold since my tests at the beginning of December 2020, but we don't know why it improved and by what update. My *guess* is that a change to the 3D dice engine did that at the end of Dec 2020 which officially was meant for "better optics".

No acknowledgement of issues + lack of in-application changelogs = no idea what's happening.

This line was redacted but it helped me come to the next line.....

Moon Wizard already said they are looking into it (not the dice rolls, that's ridiculous) - but they don't then have to give you a detailed response explaining what, why or how they are doing it.

Zacchaeus

February 5th, 2022, 13:15

This also means that any battle map couldn't even take into account any ranged combat with bows whatsoever.

For an outdoor map set the Distance multiplier of the grid to something like 20 or 30ft. This will give you acres of space to fire your bow. In most if not all dungeon maps it's unlikely that a bow will ever be needed to fire from anything over short range.

Zarestia

February 5th, 2022, 14:01

You right it is 4x (almost) than a 2048x2048 map
As we're not speaking about monitor resolution, 4k should mean 4096*4096 which is exactly 4 times bigger than 2048*2048, not almost.

Thus I was talking about ranging for bows/ranged weapons. I'm looking at it practically.
Practically, D&D (I take D&D as it is by far the most played system) was never designed to work well with VTT. Let's take a longbow with a range of 150 feet which is equivalent to 30 grids. I can't see 30 grids on any maps I own when at 100% zoom, can you? If you have to zoom out, maybe make the map just smaller, better for practical play.

If we can't use maps that are normal sized of what map makers put out, what is the point of using this VTT.
You can use any map you want, it's just not recommended.

I'm upset if this is really the stance that 4kx4k is the size we should be using else we will see crap performance.
It is the recommendation, nothing more nothing less. I don't know where you get that "crap performance".

... because I've used 50kx50k maps already with zero issues.
Aren't you contradicting yourself pretty much?

I just think that if this is the stance of 4kx4k images are "recommended" then why was this put into FGU in the first place, this is such old tech being pushed as new then?
If 4k*4k images are "such old tech", what is "such new tech"?

I'm done with this topic/thread as it's just going to end up getting locked down with no real reason given.
Most thread are getting locked down because people keep harassing SW stuff (generally the same people) and people talking nonsense.

Using the normal DPI of 72 ... Using really low DPI.
DPI is nearly irrelevant in digital images, what you mean is dots per 5 ft. grid.

Weissrolf

February 5th, 2022, 14:43

Practically, D&D (I take D&D as it is by far the most played system) was never designed to work well with VTT. Let's take a longbow with a range of 150 feet which is equivalent to 30 grids. I can't see 30 grids on any maps I own when at 100% zoom, can you? If you have to zoom out, maybe make the map just smaller, better for practical play.
This is a map bought from the SW store. It is used both zoomed in and zoomed out. In different VTT I would very likely increase the resolution of the map for better zoomed in details.
https://i.imgur.com/oA4Irtd.pnghttps://i.imgur.com/hFXseIZ.png

It is the recommendation, nothing more nothing less. I don't know where you get that "crap performance".

larger than the recommended sizes is not our primary focus
...
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
These statements might contribute to the impression. Including the next one:

...is not meaningful other than to prove that any system is stressed if you throw enough data at it
If we stay on topic VTT maps, then no, not any, just a few, like FGU.

DPI is nearly irrelevant in digital images, what you mean is dots per 5 ft. grid.
In the world of VTT maps DPI is very regularly used to describe the dots per inch corresponding to a 5 gt. grid square. It doesn't matter if the maps are used for printing or VTT, with the latter allowing end-users an idea of how detailed (resolution) the map is when zoomed in.

damned

February 5th, 2022, 15:07

DPI is a term relevant to printing
On a computer screen a 4000x4000 map at 300dpi is exactly the same size as a 4000x4000map at 72dpi
When printed at 300dpi or 72dpi then there is a difference
Pixels per unit of measurement or scale is relevant to digital maps

I have an 8yr old i5 standard desktop pc, with a 2gb gfx card and an ssd drive
Tonight we battled with 8 level 7 pcs and 42npc on an outdoor map with LoS and I did not notice any issues.

I have never run a 15x15k map before, its never been required, but I expect that my system would find that a lot harder than a 4x4k map, it might even be impossible for my old computer to run. I cant see it ever being an issue for me though. Im completely happy with the map sizes I use.

Weissrolf

February 5th, 2022, 16:19

DPI is a term relevant to printing
And a term related to VTT maps. Live with it, it happens in the real world and everyone knows what is meant by that.

Pixels per unit of measurement or scale is relevant to digital maps
Yes, and the world of VTTs has decided to use the DPI moniker for that. I did not invent it, I just relay the information. So there is little use in arguing about what's already out there.

Tonight we battled with 8 level 7 pcs and 42npc on an outdoor map with LoS and I did not notice any issues.
That's nice anecdotal feedback. But this forum keeps getting reports of users suffering from slowdowns that happen over time (3-4 hours) and memory allocation has been proven to be problematic, especially in combination with 5 minute autosave. FGU is a memory swine and the usual answer to that is "use smaller maps", but not as a temporary workaround until better solutions are presented, but as a permanent "solution".

I have never run a 15x15k map before, its never been required
Does not matter, because the 15x15k file was specifically created to make the issue easier to reproduce/debug. I also never run a 15k map of pure cyan, but you can squeeze those 225 megapixel images into a 226 kb (!) PNG file for easier uploading to the SW developers then. And it is a test-case file for easier reproduction and debugging.

And as mentioned before: commercially available map packs (usually Patreon based) regularly offer maps larger than 4k px on one side, easily up to 10k on the long side. This includes CzePeku (140px per grid), Forgotten Adventures (200px per grid) and Crosshead Studio (257px per grid) and other publishers. Chrome laughs at displaying a Crossheads 10k x 10k px map.

Before zooming to 100%:
https://i.imgur.com/dElxQUP.png

After zomming to 100%:
https://i.imgur.com/fn0aIzg.png

And FGU can also handle these kind of maps easily if it doesn't stumble over its own memory management:
https://i.imgur.com/vs4v6Km.png

Only 1 minute before I imported and then displayed the very same map with FGU using less than 500 mb memory. If I try importing or opening the same image from assets now I always get over 1.7 gb memory now. So I thought that it must have been the creation of a new campaign that made FGU release the memory at once?! Nope, same 1.7 gb now. From testing I know that I now either have to wait (10 minutes in the OP) or load another image that makes FGU release memory again. Let say, like this maybe?!

https://i.imgur.com/8OyGruA.png
Still the same image being displayed by FGU.

but I expect that my system would find that a lot harder than a 4x4k map, it might even be impossible for my old computer to run. I cant see it ever being an issue for me though. Im completely happy with the map sizes I use.
That's nice for you. But the topic of this thread is FGU regularly failing to release memory after importing or opening (only large?) images. I don't know how often I have shown that FGU can literally eat all my memory despite the content (!) not being even close to the memory used. Same non-answers every time.

LordEntrails

February 5th, 2022, 16:28

Moderation:
Everyone needs to remain polite and respectful of each other. We know where threads like this have gone before, I will be less tolerant of behavior that veers that way because everyone here has experience to draw on to know what is acceptable and not. If you are tempted to post something that you think might be questionable, step away from the thread for a day or two. Please moderate yourself so that I do not have to.

Zarestia

February 5th, 2022, 17:28

This is a map bought from the SW store. It is used both zoomed in and zoomed out. In different VTT I would very likely increase the resolution of the map for better zoomed in details.

I can't tell you anything about that 510px*649px screenshot.
I don't even know why some things always go out of control.

The response was: 4k*4k is the recommendation, larger than the recommended sizes is not our primary focus.

Just because some people scream the loudest, doesn't mean they're in the right or in majority.
Memory consumption and collection seems to work in FGU at the moment better for many <=4k images than few >4k images. I think that has been said and tested enough times by people like Weissrolf that the devs know that - it just isn't their primary focus.
Can that change? Maybe. They have a better overview of their playerbase than I do.
My guess would be that most users simply play bought modules and don't import/create their own >4k maps. I create my own maps, yes they've been over the recommendation. No, I haven't had any noteworthy problems. Yes, people have had problems but that is also each time a separate case which needs to be looked at and not somehting anyone should make their own to substantiate their own arguments.

HywelPhillips

February 5th, 2022, 17:55

I'd just like to contribute a couple of observations from my own experience.

It is sometimes very useful to use maps greater than 4K resolution, as I have mentioned in previous threads.

Here is a screengrab of two versions of the Icewind Dale player map from Rime of the Frostmaiden. On the left is the one I grabbed from D&D Beyond (where I also own the module). On the right is the one that comes with the module as purchased on the FG store.
51331

The DND Beyond grab is 4215 x 6000 pixels.

This map is the main campaign tool for this module. Having played the module and now GM'ing it, I have to say that the version that came with the FG module is not adequate, at least not for my middle-aged eyes. The players are going to spend 12 months of real time plotting their adventures on this map, and it needs to be legible at a reasonable zoomed-in level as shown above.

This map is no problem for me or my players in the higher resolution, primarily because it doesn't need LOS or lighting. But the need for legibility means that the supplied version is inadequate.

I can also confirm that all the Patreon map artists I am currently buying from are supplying their maps in formats that START around the 4k x 4k size and go up from there. Heroic maps Farhill Dwarven Trading post VTT low resolution version is 2800 x 4200. The small version of the Morvold press map for Gold Toe Mine is 4275 x 6650 pixels. The other artists whose maps I am using are providing them in similar sizes.

So while I understand that improving performance for these large maps is not currently a Smiteworks priority, I would like to flag up that things are only moving in one direction (ie higher resolution) and that the current 4k x 4k recommendation is going to become an issue going forwards.

The slowdown for me comes from using these large maps with LOS and, particularly, lighting. I have also observed the 3-4 hour slowdown although that seems to have been much improved for me in recent weeks by turning off a whole bunch of extensions.

I understand that performance tuning is a bloody difficult job and that more general improvements in the LOS and lighting system will probably have knock-on improvements on the large map performance too.

But I do think that the developers should be aware that the standard size for purchased maps from artists on Patreon, DriveThru etc. are such that the lowest pixel resolutions supplied are already at or above the recommended FG sizes, and that this is likely to be an issue going forwards.

Best regards,

Hywel Phillips

Kelrugem

February 5th, 2022, 18:19

FGU is a memory swine and the usual answer to that is "use smaller maps", but not as a temporary workaround until better solutions are presented, but as a permanent "solution".

And that is nowhere stated like that. It was about current recommendations, and of course that can change in the future. So, I do not see any reason to view those as a "permanent solution"; you can personally of course think that the development in that regard is too slow, but then do not write it as if SmiteWorks claimed that the recommendations are permanent solutions and that they do never look at improving performance anymore.

(and if you follow some other threads, then they currently look at issues related to FoW data :) )

jharp

February 5th, 2022, 19:05

And that is nowhere stated like that. It was about current recommendations, and of course that can change in the future. So, I do not see any reason to view those as a "permanent solution"; you can personally of course think that the development in that regard is too slow, but then do not write it as if SmiteWorks claimed that the recommendations are permanent solutions and that they do never look at improving performance anymore.

(and if you follow some other threads, then they currently look at issues related to FoW data :) )

SW examination of FoW data is to reduce data points, which in some cases makes sense (ie a straight line doesn't need 30 data points), but in other cases it does not. As map size increases the FoW data will increase such that SW reduced FoW might as well be GM controlled again. Game engines handle line tracing very very well. SW needs to spend some $s to get that to work in FG. A better understanding of the engine will no doubt help them in many ways, including memory usage.

Jason

jharp

February 5th, 2022, 19:16

I will provide an example of how knowledge of the unity engine would assist SW. I pointed out a security flaw in FGU that allowed arbitrary execution of code in extensions. This would allow any extension to do anything it wished on the host or players computers. Anything from installing software to deleting files (or worse). The root cause was a lack of knowledge and the use of this API in unity without any checks.

https://docs.unity3d.com/ScriptReference/Application.OpenURL.html

It took one direct message, one forum post, and 12 emails before it was acknowledge to be an issue. It then took (reasonably so) a month for the fix to be released.

SW can blame memory usage and slowness on anything they wish but ultimately it is an issue of money and knowledge base.

Jason

Kelrugem

February 5th, 2022, 19:24

SW examination of FoW data is to reduce data points, which in some cases makes sense (ie a straight line doesn't need 30 data points), but in other cases it does not. As map size increases the FoW data will increase such that SW reduced FoW might as well be GM controlled again. Game engines handle line tracing very very well. SW needs to spend some $s to get that to work in FG. A better understanding of the engine will no doubt help them in many ways, including memory usage.

Jason

I am not an expert on that, but surely the stuff with performance is not done with looking at the FoW :) Just wanted to provide an example for that performance is looked at, just maybe not as fast as some users may would like to have it

jharp

February 5th, 2022, 19:26

Understood.

Weissrolf

February 5th, 2022, 19:34

What exactly is SW looking at? Can you name something specific in regards to absurd virtual memory allocation and repeated lack of memory release? Did anyone hear what is happening in regard to memory not being released anymore if FGU is busy in the moment of an autosave happening?

Seemingly not the screenshots and files I sent them over the last year. I demonstrated that I reproduce memory leaks with the busy-autosaving situation and was not contacted about it or even given a dedicated answer. Even now that I specifically created an otherwise empty test-campaign with specifically created images for easy reproduction the answer was: sent us something else.

Yeah, no, not again, do your own homework now, I wasted enough of my time already.

Weissrolf

February 5th, 2022, 19:40

I pointed out a security flaw in FGU that allowed arbitrary execution of code in extensions. This would allow any extension to do anything it wished on the host or players computers. Anything from installing software to deleting files (or worse).
Now guess why I always opposed the idea of asking users to manually mess with permissions of their Program Files folder for FGU and circumvent the usual Windows UAC mechanics that installers should always use?! ;)

damned

February 6th, 2022, 00:54

Now guess why I always opposed the idea of asking users to manually mess with permissions of their Program Files folder for FGU and circumvent the usual Windows UAC mechanics that installers should always use?! ;)

What advice are you talking about?

Weissrolf

February 6th, 2022, 01:20

The necessity to mess with folder permissions when the original FGU installer failed to do it and even when it worked it was done in a questionable way. And even now FGU still sets write permissions to "Users" group for its program files folder to get around the Windows UAC mechanics. Better than the original "Everyone" solution and maybe best for us that the installer does not properly ask for administrative permissions to write files there.

damned

February 6th, 2022, 01:41

superteddy57

February 6th, 2022, 02:22

Weissrolf

February 6th, 2022, 02:28

Every application on my computer that is installed to %appdata%\roaming has identical permissions on my computer.
Those are (mostly) data folders, not program files, although some programs use these folders to get around program folder permission restrictions. On my setup neither FGU's program nor data files are at their default positions anyway. But we digress.

HywelPhillips

February 6th, 2022, 09:55

Just wanted to comment on the module you decided to highlight and the module was setup to work in both FGC and FGU. So it might not be the best example as it's been downsized with FGC in mind.

Hi,

Yes, sorry, I was rather conflating two things, but both are relevant to the suggested size limits of 4k x 4k for image files in FGU for best performance.

As I've commented in previous threads, the FGC resolutions are not adequate for my eyes on my iMac screen (5k resolution, plus a 4K second monitor). I have made a suggestion that higher resolution versions of assets, maps especially, be made available for purchased products to cater for the two rather disparate sets of gamer- the ones running 1080p on an eight-year-old laptop screen and the ones running multiple 5K monitors. I put that in the idea informer here:
https://fgapp.idea.informer.com/proj/?ia=137527

That suggestion still stands - I'd love to have updated assets for older purchased modules, and I'd definitely prefer to have newer modules provide maps in resolutions more suitable for use on 5k monitors.

The point that was more germane to this discussion is that maps supplied by external artists and those provided for WOTC products on other platforms are ALREADY at or over the 4k x 4k recommendation. It is therefore not an unreasonable thing to expect users with decent-spec computers to be using them already without prior by-hand downsampling for FGU use. What users can and will do is to bring in the "VTT format" version of the map and expect FGU to be able to cope with it.

Resolutions never go down (at least never in my experience of 30 years of using the web) so the fact that the common external sources of maps are already blowing past the suggested FGU map size recommendations is something that should at least be flagged as a coming concern. As I said, I know performance tuning can be devilishly hard to do, and core improvements to LOS and lighting may address the large-map issues anyway.

The use of the Icewind Dale map was to supply an example where a 4k x 6k map was justified and reasonable. For sure, I could have downsampled the map after grabbing it from D&D Beyond, but I didn't. Likewise, the users buying maps from Heroic maps and Cze and Peku and Tom Cartos and everyone else could downsample the lowest-res VTT maps before bringing into FGU... but they won't :) They'll import them as-is and bitch about performance.

I don't think many people would gripe too much if they bring in the 300 pixels per grid square map versions intended for printing and find out the system grinds to a halt. But the versions flagged as being for VTTs will get imported straight in, and it is not unreasonable to expect them to work as-is if they work as-is on other platforms.

So it was just a hands-up to say that I for one am already routinely using maps above the 4k x 4k limit and expect the fraction of people so doing to increase as time goes on.

Cheers, Hywel

superteddy57

February 6th, 2022, 11:16

Hi,

Yes, sorry, I was rather conflating two things, but both are relevant to the suggested size limits of 4k x 4k for image files in FGU for best performance.

As I've commented in previous threads, the FGC resolutions are not adequate for my eyes on my iMac screen (5k resolution, plus a 4K second monitor). I have made a suggestion that higher resolution versions of assets, maps especially, be made available for purchased products to cater for the two rather disparate sets of gamer- the ones running 1080p on an eight-year-old laptop screen and the ones running multiple 5K monitors. I put that in the idea informer here:
https://fgapp.idea.informer.com/proj/?ia=137527

That suggestion still stands - I'd love to have updated assets for older purchased modules, and I'd definitely prefer to have newer modules provide maps in resolutions more suitable for use on 5k monitors.

The point that was more germane to this discussion is that maps supplied by external artists and those provided for WOTC products on other platforms are ALREADY at or over the 4k x 4k recommendation. It is therefore not an unreasonable thing to expect users with decent-spec computers to be using them already without prior by-hand downsampling for FGU use. What users can and will do is to bring in the "VTT format" version of the map and expect FGU to be able to cope with it.

Resolutions never go down (at least never in my experience of 30 years of using the web) so the fact that the common external sources of maps are already blowing past the suggested FGU map size recommendations is something that should at least be flagged as a coming concern. As I said, I know performance tuning can be devilishly hard to do, and core improvements to LOS and lighting may address the large-map issues anyway.

The use of the Icewind Dale map was to supply an example where a 4k x 6k map was justified and reasonable. For sure, I could have downsampled the map after grabbing it from D&D Beyond, but I didn't. Likewise, the users buying maps from Heroic maps and Cze and Peku and Tom Cartos and everyone else could downsample the lowest-res VTT maps before bringing into FGU... but they won't :) They'll import them as-is and bitch about performance.

I don't think many people would gripe too much if they bring in the 300 pixels per grid square map versions intended for printing and find out the system grinds to a halt. But the versions flagged as being for VTTs will get imported straight in, and it is not unreasonable to expect them to work as-is if they work as-is on other platforms.

So it was just a hands-up to say that I for one am already routinely using maps above the 4k x 4k limit and expect the fraction of people so doing to increase as time goes on.

Cheers, Hywel

No worries, just wanted to bring up that it was made with that intention. Didn't know if that would change any of the information you were giving, just wanted to let it be known.

Egheal

February 6th, 2022, 13:14

What about a poll that would be sent by Smiteworks to all their users about this kind of issues ? Could be a good way to evaluate the significance of the problem and what the silent majority is thinking about it in general.

Valyar

February 6th, 2022, 17:14

I am pretty sure Smite Works are aware of the issue and working on it. Not everything can be addressed immediately or easily.

Weissrolf

February 6th, 2022, 19:17

What makes you sure of that? Did you read any official communication on that matter as to where they are and where they want to be? Would you provide a link to that information?

Jiminimonka

February 6th, 2022, 19:22

I am pretty sure Smite Works are aware of the issue and working on it. Not everything can be addressed immediately or easily.

Yeah, I have read enough messages from JPG and DD etc., that this is clear and obvious.

LordEntrails

February 6th, 2022, 22:34

SmiteWorks has made it clear that per policy they do not and will not lay out a feature roadmap, nor detail what they are currently prioritizing. It is also clear that some community members will never be happy with this policy. They are free to be unhappy about the policy, but it is not something the community can change and arguing about it or reiterating one's dislike of this policy does not help the community. Please refrain from beating your head against the wall no matter how important you feel an issue is. State your opinion if you have not already, add the item to the wish list if it is not already there and vote on it, AND MOVE ON.

God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.

- Reinhold Niebuhr

jharp

February 6th, 2022, 23:38

Lol

Lo Zeno

February 8th, 2022, 00:04

Every application on my computer that is installed to %appdata%\roaming has identical permissions on my computer.
That is products by
Adobe
Affinity
Atlassian
Audacity
Discord
Dungeondraft
SmiteWorks
FileZilla
GIMP
Microsoft
etc etc

All have System, Me, Administrators
He is talking about the executable inside the Program Files folder (C:\Program Files\SmiteWorks\Fantasy Grounds\FantasyGrounds.exe), which has its permissions set to "Full control" to Users. This is generally seen as bad practice and a security concern, since only the SYSTEM user and the Administrators group should have Write permissions to files in %ProgramFiles%, and normal Users should only have Read and Execute permissions. See here FGU's permissions in Program Files vs two other programs installed in Program Files:
51377

If you make a non-admin account for your kid, for example, it's because you don't want to risk that your kid might accidentally delete/uninstall a program that you use. If an executable needs to be 100% manageable (including Write permissions) to a single user, the current preferred Windows installation location would be %LocalAppData% (aka <user>\Appdata\Local), while still using Appdata\Roaming for settings and data files.
Ideally, there should never be an instance in which an executable has Write permissions assigned to all users.

Moon Wizard

February 8th, 2022, 00:07

I was able to have a conversation about these topics with Carl today, now that he is back in the office and getting caught up. We reviewed the code in place, and talked about some various thoughts that we had and things to try.

Back to the original question that started this ride:

The asset management system in FGU which handles all image assets (ruleset frames/icons/etc, graphic assets, etc.) is on a 5 min timer, with a 10 min TTL for each graphic asset. Since one of the most expensive operations in FGU in terms of performance is loading data from disk, this is to prevent issues with people closing windows and opening them up within several minutes to look at the same image/data and getting slowdowns during normal play behavior.

For the related question on load times of very large images:

The basic result of the discussion with Carl is that very large images are a lot of data that has to be loaded into a texture that can be sent to the GPU by the Unity game engine. (The recommended image size is 16 megapixels; while the samples provided by Weissrolf ranged from 36 megapixels to 225 megapixels. As mentioned earlier, this is 125% larger to ~1300% larger than the recommended sizes.)

For a point of reference, I opened one of the sample 225 megapixel images provided in the following applications:
* Current test build of FGU: 5s
* Google Chrome: 2-4s
* Photoshop 2021: 5.5-6s
* MS Paint: 5s
Considering the kind of operations we need to perform, I expect us to be closer to Photoshop and MS Paint than Chrome in general.

One thing to also remember is that this is for a machine running a SSD local drive, and does not include other factors that could apply (alternate drive paths/technologies (external/network/HDD/etc.), network transfer times (for remote clients), ...)

All that being said, we did talk about any ideas we had about potentially speeding up the load times within the limits of Unity, texture sizes and libraries. We currently use the Google Skia library to load and tile images in FGU as 2k x 2k tiles. To that end, we tried some alternate ideas today that seemed like they might be faster on the surface. (including using native Unity image loading library; increasing tile sizes to 16k x 16k; bypass tiling in degenerate cases; etc.) However, all the changes we tried were comparable or slower than the current implementation.

Regards,
JPG

Moon Wizard

February 8th, 2022, 00:14

Additionally, per a suggestion from Carl, I will be adding a "/gc" chat command that will perform an immediate asset removal (i.e. 0 TTL), as well as a system garbage collection.

Regards,
JPG

Jiminimonka

February 8th, 2022, 00:18

Nice!

Weissrolf

February 8th, 2022, 00:21

My original question was not about performance, though, but about

1. Much more memory being allocated than needed to work with the image once loaded.
2. Said extra memory not being released within the first 10 minutes, unless forced to being released by loading certain other images.

Look at my Chrome vs. FGU memory allocation again. Chrome uses less memory than the image's 24-bit bitmap size once it's loaded into the GPU (likely as 16k x 16k tile, which is also what Foundry does). And even software that does pure software rendering on the CPU can release any extra memory needed for things like JPEG decoding once the bitmap image is fully loaded into memory. E.g. a 200 mb 24-bit bitmap image should not use much more than 200 mb memory once loaded.

And again: this is about memory, not performance. The 10 min TTL to protect against accidental window closing is fine, but waiting 10 minutes to release unused data from memory is not. FGU needs to have as many of its memory leaks closed as possible in order to clean the house on the various slowdowns happening after longer usage and to allow low performance PCs to run smoother in general.

PS: Anyone tempted to write (again and again and again) something about "200 mb (JPG) image files? who would need that?": Don't! You do not understand the difference between lossy compression and decoded images in memory.

damned

February 8th, 2022, 00:36

He is talking about the executable inside the Program Files folder (C:\Program Files\SmiteWorks\Fantasy Grounds\FantasyGrounds.exe), which has its permissions set to "Full control" to Users. This is generally seen as bad practice and a security concern, since only the SYSTEM user and the Administrators group should have Write permissions to files in %ProgramFiles%, and normal Users should only have Read and Execute permissions. See here FGU's permissions in Program Files vs two other programs installed in Program Files:
51377

If you make a non-admin account for your kid, for example, it's because you don't want to risk that your kid might accidentally delete/uninstall a program that you use. If an executable needs to be 100% manageable (including Write permissions) to a single user, the current preferred Windows installation location would be %LocalAppData% (aka <user>\Appdata\Local), while still using Appdata\Roaming for settings and data files.
Ideally, there should never be an instance in which an executable has Write permissions assigned to all users.

That is probably correct.
The FG app on many peoples computers will have updates to be applied every week and the updates are recommended to be applied.
Installing to %LocalAppData% means you would have multiple installs.
Leaving install where it is with enhanced (lower?) permissions means its a single install available to all users.

I think there was a build of FGC once that when you did the UAC to install it retained the UAC permissions on that launch of teh software and then any campaigns you created in that session had different owner/permissions and were not accessible to the next launch. I dont know if that history has something to do with this current model.

Lo Zeno

February 8th, 2022, 08:00

That is probably correct.
The FG app on many peoples computers will have updates to be applied every week and the updates are recommended to be applied.
Installing to %LocalAppData% means you would have multiple installs.
Leaving install where it is with enhanced (lower?) permissions means its a single install available to all users.

I think there was a build of FGC once that when you did the UAC to install it retained the UAC permissions on that launch of teh software and then any campaigns you created in that session had different owner/permissions and were not accessible to the next launch. I dont know if that history has something to do with this current model.
I'm pretty sure that's the reasoning they used for this choice, and that they wanted to avoid a (very common) situation in which only one or two users have Administrator accounts but the program is used by many more users, which would mean that in order to update the application they'd have to HOPE that the administrator applies them regularly. It still is not a sensible choice.
This problem (making a single install available to all users while allowing updates to be constantly applied without relying only on one administrator user) is a solved problem, as it's exactly what Chrome, Firefox, Opera and any browser do (and not just browsers actually): have the updating operation performed by an updater service, which runs under the System user. If you open your Task Manager and you go to the Services tab, you'll see that there's one called "gupdate", its description is "Google Update Service" (if you have Firefox or Opera and have automatic updates enabled, you'll see equivalent services). If you look at its properties the LogOn tab will show that it's logged on as "local system account". This gives it Full Access permissions to applications installed on %ProgramFiles% (and other locations), and can be invoked by a User account to perform its operations: given that updater services are built with only specific operations in mind (in this case, update a program) there's no risk that it's used, for example, by a user to mistakenly delete a single file in the installation folder.
In FGU context, what the FGUUpdater application should do is invoke an FGUUpdaterService to perform the update on the FGU installed app. This solves the problems of user availability, of update applications, and the security concerns. It's the recommended approach for developing auto-updating Windows applications, not some industry secret.

In fact, if Moon Wizard is reading, I hope he'd consider that in this forum community he has people he can contact for consultation on these things instead of re-inventing the wheel for established patterns, and for this specific situation there's even a few pre-packaged solutions to use so that they don't need to code their own updater service: like Omaha (https://github.com/google/omaha), the open source version of the Google Updater service. (https://omaha-consulting.com/google-omaha-tutorial-chrome-updater)

Weissrolf

February 8th, 2022, 08:10

If FGU users use computers where only 1 or 2 users have administrator accounts but the program is used by many more users then the problem is those users abusing work computers for FGU. :P

Lo Zeno

February 8th, 2022, 08:33

If FGU users use computers where only 1 or 2 users have administrator accounts but the program is used by many more users then the problem is those users abusing work computers for FGU. :P

Imagine I am a dad with three young kids: I don't want my kids to have Administrator accounts on the family PC, yet I'm happy for my kids to play D&D with their friends.
Suddenly you have a pretty common situation where only 1 user is an Administrator account but the program is used by many more users and it's not a work computer.

Weissrolf

February 8th, 2022, 09:03

Lo Zeno

February 8th, 2022, 09:20

I imagine that your kids either can live with FGU not being updated every week, or you could enter your dad password once a week if needed. Alternatively you could just install FGU in a different directory that the kids have write access to, which is what I do. But when the default "Program Files" directory is used then the permissions should not be messed with.

You really don't have kids, do you?
Also, do you really think there are no legitimate reasons why people have non-admin accounts in their non-work computers? Then you live a very sheltered life, lucky you.
I could list you here the number of times I had to spend days or a week away from home for work and I wouldn't be able to sit with them at a computer - and no, sometimes I don't have the time to find a WiFi in time to remote in with TeamViewer, and no at times if I am travelling for work (before Covid, that is) I might find myself in another timezone than home. I could list you the dozens of other times they had friends over and I was so glad I did not allow anyone to know the Administrator account.
Or I could mention that the demographic of my company's customers is made of users who need, for different reasons, non-admin accounts at their home PCs, so I am not pulling stuff out of thin air.

I could also point out to you that in the post I wrote before yours I not only acknowledged that permissions in Program Files should not be messed with, but I gave the practical and easy solution to how SW can solve the updates problem without messing with user permissions - go on and read it. So don't act like I was dismissing your point, please.

Weissrolf

February 8th, 2022, 09:34

Lo Zeno

February 8th, 2022, 09:45

I do have kids (not using PCs yet), but when they would need software with update rights then I would install said software in a different folder. Even on my own computer all games are installed in their own folder instead of Program Files. I am not too fond of update services, which tend to cause unnecessary extra load and like to collect telemetry data. Google Chrome's service is the worst on weak computers.

And in the post before yours I made a tongue in cheek comment about not using FGU on work computers, :P stuck out tongue emoji included.

1- not everyone is comfortable or knowledgeable enough to trust installing applications in non-standard folders - while Windows (specially with Windows 11) directs you to create non-admin users first, when you create new users. There are more people who crete non-admin users than people who know what happens when you install in non-standard locations. For example, the almost totality of users can't tell what different effects have an installation under C:/aCompletelyNewFolder and under the UserFolder.
2- Update Services are just applications - they can be bad or good depending on the way they are coded. Between the current FGU approach and an update service, the latter is objectively better.
3- A tongue emoji is not universally recognized as meaning "I made a tongue-in-cheek joke", especially when you use it with people with whom you don't have a close relationship. There's many, many, many reasons why I once called you "abrasive", and this is one of those: you lack awareness of how your writing approach is perceived when read over a forum.

Weissrolf

February 8th, 2022, 09:49

Thanks for contributing to the topic of "unused memory not being released" instead of derailing the thread into just a discussion about my personality. Your effort is acknowledged and appreciated.

This was the last post on-topic, hopefully it doesn't get lost: https://www.fantasygrounds.com/forums/showthread.php?72373-Questions-regarding-image-memory-garbage-collection&p=639394&viewfull=1#post639394

mapleybacons

February 11th, 2022, 16:27

Throwing my 2 cents in here because we ran into some issues with slow down as well.

For context, our group frequently uses 10 to 25MB maps at 100 to 150 pixels per grid (so upwards of about 40 x 80 grid squares) with LOS and lighting. We have a group of five located across the US. We use locked token movement because it helps plan out movement and prevent accidental movement of tokens.

A couple things we noticed is map size doesn’t really impact performance… it does take up a bunch of RAM and may take a minute to load, but once it’s loaded the actual map size (squares and filesize) don’t really matter. However, LOS and lighting both have noticeable impacts (which has gotten a lot better in the past couple of patches). Keeping the number of occluded nodes low helps with LOS, but lighting can feel inconsistent… except for lighting on a token which always has the greatest impact to performance. We’ve developed a few ways around lighting when we need to like using ambient lighting when it makes sense and we’ve noticed setting a VISMAX on character tokens seems to limit the number of walls/nodes being tested while the token is moving.

There were a couple other impacts to performance that weren’t so obvious.
~ Keeping the db.xml file slim helps with saving… if you can make a module for maps then load/unload as needed it’s a lot better than importing a map into your campaign because LOS data persists even after deleting the map from the campaign. Some combat records and NPCs persist in the campaign db.xml too which is odd.
~ The chat history has a huge impact on save speed when it starts to get over 1MB. I’m not really sure why the chat history doesn’t automatically archive itself like the db.xml file does, but you can have months and months of history stored in it that is re-parsed on every save. We ended up deleting ours, but a better tip would be to rename it with a date stamp (which FGU will then ignore).
~ Lastly, we were having terrible performance issues until one of our players started using a VPN. This isn’t something I’d expect SmiteWorks to have much, if any, control over, but it seems like if the host or players normally get their internet traffic routed through a bad server node, it can cause a lot of headaches. Not all VPNs are created equal, but some can help with changing your routing. Since this change we haven’t even had much trouble with LOS & lighting, so maybe there’s something in the FGU net code that is transferring too much data between the host & clients when something is moving on screen like tokens or dice rolls? I don’t know how it’s working, but to me it seems like a simpler way of doing things would be to send the start, waypoints, and stop points between host & clients then let each computer draw what’s happening independently… because it seems like data is being sent at every point along the path (same for dice rolls).

Idk. Work in progress for performance pro tips.
Cheers everyone :)

jharp

February 11th, 2022, 16:37

The VPN item is particularly interesting.

Sterno

February 12th, 2022, 12:49

A couple things we noticed is map size doesn’t really impact performance… it does take up a bunch of RAM and may take a minute to load, but once it’s loaded the actual map size (squares and filesize) don’t really matter. However, LOS and lighting both have noticeable impacts (which has gotten a lot better in the past couple of patches). Keeping the number of occluded nodes low helps with LOS, but lighting can feel inconsistent… except for lighting on a token which always has the greatest impact to performance. We’ve developed a few ways around lighting when we need to like using ambient lighting when it makes sense and we’ve noticed setting a VISMAX on character tokens seems to limit the number of walls/nodes being tested while the token is moving.

Can you talk a little more about VISMAX? I hadn't heard of that before.

Jiminimonka

February 12th, 2022, 13:01

Can you talk a little more about VISMAX? I hadn't heard of that before.

I have VISMAX setup in Savage Worlds as a Global Effect (I think this is exclusive to Savage Worlds), so it limits how far the players can see.
51462

Zacchaeus

February 12th, 2022, 13:39

Can you talk a little more about VISMAX? I hadn't heard of that before.

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1315930113/Player+and+NPC+Token+Vision+on+Maps

Weissrolf

February 16th, 2022, 18:24

VISMAX does not improve performance on large maps with many LOS points when FGU is CPU bottlenecked. You still need to delete LOS points for that, because FGU calculated LOS beyond VISMAX and through dozens of closed walls. And it is another issue than the one discussed here. There has been a thread about it, but of course it has been closed without the issues being solved or the workaround being acknowledged.

https://www.fantasygrounds.com/forums/showthread.php?56503-FGU-using-GPU-at-almost-100&p=588166&viewfull=1#post588166

MrDDT

February 16th, 2022, 18:33

Weissrolf

February 16th, 2022, 19:33

From what I understand VISION does the same for normal vision as VISMAX. And both VISION: 10 or VISMAX: 10 make no difference compared to no such effect on the token.

Weissrolf

February 16th, 2022, 19:42

New DnD5E campaign, one large image imported, nothing else. This is the elephant in the room (concerning this thread):
https://i.imgur.com/LVxEfMh.png

The following memory usage needs to be added to the Chrome result (Foundry server):
https://i.imgur.com/PidhHb1.png

MrDDT

February 16th, 2022, 19:58

From what I understand VISION does the same for normal vision as VISMAX. And both VISION: 10 or VISMAX: 10 make no difference compared to no such effect on the token.

Ok thanks.

Sorry to derail it just another question. Are you saying that VISION: 10 and VISMAX: 10 are exactly the same in all ways? I'm not of the mind it isn't I'm just confirming.

I agree with you on the main point of this thread is that large images shouldn't be using so much memory and also need to release it faster as other programs do.

Weissrolf

February 16th, 2022, 20:02

This is my understanding for normal vision, yes.

Normal Vision (unlimited range)
VISMAX: Standard vision is reduced to the specified range
VISION: {range} {type}
* If type is not specified, it will apply to normal vision

Weissrolf

February 16th, 2022, 20:03

Dakadin

February 16th, 2022, 23:01

Weissrolf,

How big was the image you imported and did you have anything else loaded?

I am trying to replicate it and I am not seeing the same thing you are so I am curious what I am missing. I used a 4800x6000 pixel image that is 28 MB jpeg file.

For FG, I loaded the 5E ruleset without any modules and then imported the image.

For Foundry, I loaded the world using the DND5e system without anything else and then created a scene and used the image as a background image.

The usage looks pretty similar to me but I know that Chrome uses multiple processes that can use memory for other things.

Here is what it looked like for my test:
51521

Here is what it looks like 5 minutes later:
51522

What am I missing? Do I need to put LoS and Lighting on both maps?

Zacchaeus

February 17th, 2022, 00:17

See post #3

Weissrolf

February 17th, 2022, 00:33

How big was the image you imported and did you have anything else loaded?
For the latest screenshots I used the "Caves of Chaos-PC_highres.jpg" (14200 x 10200 px) from the "Keep On the Boderlands" campaign as provided by another user in the old GPU load thread. It's a real campaign that someone less vile painted than me used for real. Nothing else loaded, no walls, no nothing.

https://www.fantasygrounds.com/forums/showthread.php?56503-FGU-using-GPU-at-almost-100&p=587997&viewfull=1#post587997

The reason I used that campaign/map was to have comparable data to the old and still relevant workaround when I tested VISMAX and VISION quickly to assess their use for performance.

Dakadin

February 17th, 2022, 02:33

Thanks. I was able to get closer to what you were seeing by importing the Caves of Chaos_highres.jpg file into both. The interesting thing is FG is actually showing less memory usage after a few minutes for me.

Initial load:
51523

5 minutes later:
51524

Maybe a recent update is cleaning up the memory better than when you ran it. I am also seeing more memory usage using Foundry than you did but I have no idea why that would be.

CPU and GPU are being used more by FGU though.

Dakadin

February 17th, 2022, 03:49

I also tried the cyan images Weissrolf provided in a new campaign in FGU and world in Foundry because I was curious how they would behave with those images.

Here are my initial results after loading the 15k jpg file:
51525

5 minutes later:
51526

Then I figured I would try loading the 15k png file. Here is the initial load after doing the jpg file. FGU added about 2 GB while Foundry added about 1.4 GB even though it is showing more memory being used:
51527

5 minutes after that:
51528

I am seeing that FGU frees up the memory more than Foundry in my tests. I didn't do the test with any modules loaded so not sure how that would change things though.

Weissrolf

February 17th, 2022, 09:12

You are seeing less memory after some time, because of what I wrote in the OP and Moon Wizard confirmed.

The asset management system in FGU which handles all image assets (ruleset frames/icons/etc, graphic assets, etc.) is on a 5 min timer, with a 10 min TTL for each graphic asset.
But 10 minutes to release unused memory is too long and often enough does not even work, as shown in my last screenshot and other threads before (e.g. keeping FGU busy while the 5 minute autosave happens breaks memory management).

PNG file behavior is also different from JPEG behavior in that PNG usually needs less memory to be imported/loaded. This is consistent with other applications' behavior (and also applies to TIFF).

Last but not least, loading multiple images affects the behavior. But that all was already reported earlier and the official reply was unsatisfactory. So again, I don't really care at this point and thus draw my own conclusions and spend my money accordingly.

Dakadin

February 17th, 2022, 19:05

I just did my tests because new results were posted yesterday but definitely use whatever application works best for you.

In my tests FG didn't take 10 minutes, it only took a few minutes but as you said I wasn't actively doing anything in either application so that could definitely be a factor. I was actually surprised that it cleared up that much especially compared to the Foundry results. But this was just a quick test of just loading the images. There is going to be quite a bit more involved in running an actual game and that makes it tough to do comparisons like this.

mapleybacons

February 17th, 2022, 20:13

Weissrolf

February 17th, 2022, 21:33

I just did my tests because new results were posted yesterday but definitely use whatever application works best for you.
I always appreciate every community contribution to testing and sharing results and discussions even more so.

Jiminimonka

February 17th, 2022, 22:10

This is very interesting… I might do some testing on it myself. Are you sure this is still true though? We’ve had a couple patches since last March that had noticeable improvements towards LOS and lighting.

VISMAX is to stop players seeing far, useful on some maps, not to reduce CPU/GPU overhead.

mapleybacons

February 17th, 2022, 22:50

VISMAX is to stop players seeing far, useful on some maps, not to reduce CPU/GPU overhead.

K. Intuitively, it feels like it should since the token LOS distance appears shorter (therefore limiting the number of occluder nodes the token's vision appears to be interacting with), but I can accept that's not the case. It'd be nice if one of the devs weighed in on this (or a link to where they have already) instead of hearsay, anecdotes, and assumptions though.

Anyway, I'm running some LOS tests and noticed something about memory management.

The initial load of an image into a campaign or loading an image from a module I see RAM usage spiking relative to the file size or number of pixels. This has been stated before.

However, I noticed after closing the image and letting FGU release the RAM associated with the import / first opening of the image, subsequent opening of that image doesn't appreciably increase RAM usage and working with tokens, even on a map with a ton of occluder nodes, is much smoother.

Jiminimonka

February 18th, 2022, 09:21

K. Intuitively, it feels like it should since the token LOS distance appears shorter (therefore limiting the number of occluder nodes the token's vision appears to be interacting with), but I can accept that's not the case. It'd be nice if one of the devs weighed in on this (or a link to where they have already) instead of hearsay, anecdotes, and assumptions though.

Anyway, I'm running some LOS tests and noticed something about memory management.

The initial load of an image into a campaign or loading an image from a module I see RAM usage spiking relative to the file size or number of pixels. This has been stated before.

However, I noticed after closing the image and letting FGU release the RAM associated with the import / first opening of the image, subsequent opening of that image doesn't appreciably increase RAM usage and working with tokens, even on a map with a ton of occluder nodes, is much smoother.

The devs have weighed in on it a few times. I'm not going to go looking for links to posts, but they have, are aware of issues and working on it (along with everything else a small team of developers with a massively complex piece of software have to deal with).

EDIT: Re: Image, did you close the image and re-share it, or just close it and re-open?

mapleybacons

February 18th, 2022, 15:02

Just close, let FGU release the memory, and re-open it.

It seems that if you import or open a new image, FGU won’t release that RAM until the image is closed and the timer expires. I tried opening several images while monitoring RAM usage and no matter what size image was opened it seems like FGU allocates about 1GB plus a little extra depending on the pixel count of the image. Opening a bunch of images in quick succession doesn’t reserve more RAM per image, so it may be forcing FGU to close images in a First In First Out scheme.

I was testing by myself yesterday. Today or tonight I’ll see if I can get one of my players to help test sharing/un-sharing. It’s my understanding that once the image is shared it doesn’t have to be re-transmitted to players, though I’m not 100% clear if that’s the case when the DM un-shares the image. So, for testing with a player we’ll monitor RAM usage for:

1. Share, player closes image, wait for FGU to release RAM, player opens image (double click Token icon on character sheet)
2. Share, player closes image, wait for FGU to release RAM, DM re-shares image <- this should just reopen the image on the player’s screen
3. Share, wait for FGU to release RAM, DM stops sharing image, DM re-shares image

Idk. If any of that works, it may be something like a best practice to share images early while everyone is still getting ready for the first 10ish minutes of a session.
As I mentioned earlier though, we saw a noticeable improvement with lag when one of our players started using a VPN when connecting to the game… I realize that doesn’t have anything to do with RAM usage, but it might be related if we’re discussing performance in general.

Jiminimonka

February 18th, 2022, 15:28

I always share maps before the players join so it gets downloaded when they connect to the table.

mapleybacons

February 18th, 2022, 15:41

I always share maps before the players join so it gets downloaded when they connect to the table.

That is a neat idea. Do the images stay closed for the players when they log on?

Jiminimonka

February 18th, 2022, 16:09

That is a neat idea. Do the images stay closed for the players when they log on?

Yeah, they are closed but in their image list.

jharp

February 18th, 2022, 18:45

Transfer delay should likely be on the radar for improvements as well. When testing, I find the "transfer" between host and my own machine is much too slow.

I'm sure this issue is already known but maybe that would help actual remote players as well.

Jason

Weissrolf

March 25th, 2022, 12:00

I did some tests with the current version of FGU:

- Automated garbage collection (of the chat?) still gets disabled/broken when FGU is busy doing other stuff while an autosave (5 min) happens. If left alone for long enough (FGU idle) it does seem to fix itself now, though, and starts to release memory again.

- Manual GC works even *while* FGU is busy. As in, the same busy that breaks automated GC during autosave.

- Manual GC can lead to increased memory consumption in some cases. This happens when you leave FGU alone for so long that its automated GC cleans up a lot, even while keeping large images fully workable. I had a case where automated GC lowered memory consumption to below 300 mb, but then manual GC increased it over 1000 mb again.

- Manual GC should only be applied while used images/maps windows are left open. If you apply it after closing said windows it will throw out so much data that reopening the windows will take longer time/processing as if they were opened for the first time. If you apply it while leaving image/map windows open the extra processing is not necessary upon close/reopen.

I told my player with the super potato PC to use manual GC after the initial loading of FGU and after switching maps. At least he did not experience any crashes or desyncs last time we played. He did not report the /gc process to cause any notable delays, so even on his potato PC it seemed to work fast enough.