CPU multi-threading planned

[Weissrolf]

Ahoi.

Are there any plans on making FGU CPU multi-threaded? Like calculating all LoS on its own thread (or may even PC and NPC on their own), networking on its own thread, dice rolling and/or combat tracker automations, drawing of maps and fx, LUA extensions/scripts and the like...

[Moon Wizard]

Multi-threading will be considered when needed and when appropriate. Some things are already multi-threaded (Ex: Networking/Sharing), some things are under consideration for multi-threading (Ex: LoS calculations), and some things can't be multi-threaded (Lua engine and UI interaction).

Regards,
JPG

[Weissrolf]

- Good to know that networking is multi-threaded, so that the networking threads can keep doing its work when everything else is bottlenecked.

- LoS calculations lead to drops in frame-rates when tokens are moved, so this would likely benefit from multi-threading. Good to know that it's already under consideration.

- Are Lua scripts interpreted during runtime or compiled when a campaign is loaded? Loading a campaign is bottlenecked by a single mono thread and takes 20 seconds even on my 9900K (while no progress bar is shown). Couldn't anything of this be balanced over more CPU threads? Like compiling different modules/extensions on different threads? Some of my players are on weaker PCs and connections, so speeding up the startup time would be appreciated.

-

[bmos]

- Good to know that networking is multi-threaded, so that the networking threads can keep doing its work when everything else is bottlenecked.

- LoS calculations lead to drops in frame-rates when tokens are moved, so this would likely benefit from multi-threading. Good to know that it's already under consideration.

- Are Lua scripts interpreted during runtime or compiled when a campaign is loaded? Loading a campaign is bottlenecked by a single mono thread and takes 20 seconds even on my 9900K (while no progress bar is shown). Couldn't anything of this be balanced over more CPU threads? Like compiling different modules/extensions on different threads? Some of my players are on weaker PCs and connections, so speeding up the startup time would be appreciated.

-A progress bar for initial campaign load would be great, too, but might further increase load times as some initial calculation would need to be done to figure out everything that needs to be loaded.

[Weissrolf]

Just like in the olden DOS day: anything that moves helps to show that the program did not freeze. Most of these progress bars don't properly predict time/percentage anyway.

[bmos]

Just like in the olden DOS day: anything that moves helps to show that the program did not freeze. Most of these progress bars don't properly predict time/percentage anyway.For this I would recommend one of those 'pulsing' progress bars or a spinning circle type loading indicator (which is probably what you mean).
Early-on with my newest group (who were all new to FG) most did not have patience and kept thinking the program had failed and would close/re-open which would start the loading all over again!
It is good practice to be patient :D but also counter-intuitive to many people who are used to responsive UIs (and most people are not patient).

[Weissrolf]

While we are at it: FGU can take a long time to start (especially after updates) while seemingly being frozen "not responding". A progress indicator would help then.

[Weissrolf]

And yes, make that progress indicator multi-threaded if needed, so that the whole process does not stall to a seemingly frozen state.

[Weissrolf]

I have to underline this repeatedly: FGU desperately needs multi-threading for its UI elements. Today I had to tell 5 players that: No, FGU did not crash, despite it saying "not responding". It's just so busy processing stuff that its sad single-threaded process had no resources spare to keep its UI animated and responding.

After a promoted "complete rebuild from the ground up" this is an inconceivable design/implementation choice for 2020 software. FGU is brand-new and already feels like 20 year old software.

[fubeca150]

Unfortunately, a small team that can financially maintain itself doesn't get the needed infusions of modern software development practices through attrition and new hires. Freezing UI while crunching is indicative of using the UI thread to do calculations, which in any current software is a no-no, but especially in a game engine. The fact the problem exists is indicative of bad architecture, which is indicative of ... and so on.

Unfortunately many available tutorials for the Unity engine tend to do everything on the UI thread and only developers that already know what they are doing would be able to say "hmm, wait a second here..." As a platform Unity seems a bizarre choice to me when there is at least one other non-gaming platform that would seem to be a better choice if only because it doesn't come with all the extra overhead of a full game engine and the constraints it brings. Plus, every Unity engine update tends to break things.

The amount of effort to fix bad architectural design in the a project built in the Unity Engine would be cause to rewrite all by itself.

I'm thinking we either live with it and continue using FGU, or we don't and we don't.

[Weissrolf]

Intel Core 2 was introduced in 2006 and multi-core CPUs are widely used ever since. Publishing "completely rebuild" software that is not multi-threaded and "not responding" in 2020 is quite a tragedy.

[Sgt.Rock008]

A progress bar or spinning wheel or whatever to indicate that the program is loading or working and hasn't frozen would be super helpful. This seems like a rudimentary thing, why is it not being implemented?

[fubeca150]

The issue here is that the rendering thread is stuck doing processing. That means that a progress bar and spinning wheel will also be frozen. The UI isn't responding to draw events (because it's already in one), so adding a frozen progress bar or frozen wheel will increase the feeling that it's crashed rather than alleviating the issue. In old-school windows programming you could pump the message queue to make it seem like the UI is still working (and update progress bars). There's nothing to pump in the Unity because of the way it calls each component for an update.

Multi-threaded UI is a misnomer. There is only one render thread, after all, and it has to be synchronous because of the way the drawing is layered, and is therefore not multi-threaded.

Multi-threading doesn't come for free "even in 2020". It requires appropriate forethought, planning, and architecture. It isn't the kind of thing that is easy to add in retrospect, and it isn't the kind of thing that just happens without intent.

There are a few programming platforms that make multi-threading easier (such as Go, javascript, .NET), but those still fall prey to issues with contention, race conditions, deadlocks, dirty data, etc., if not done properly.

The Unity engine assumes that there will be a little bit of calculation every frame. The last time I worked with Unity engine it still suggested doing everything in small increments as the component is called. Creating parallel (multi-core) or multi-threaded (same core, different thread) in Unity wouldn't be trivial for this kind of app. If the developers already knowledgeable about how to use parallel processing and multi-threading then learning how to do it in Unity really isn't a good place to start.

That's not to say it's impossible... it's just necessary to address each freeze individually by moving it to process asynchronously and render the state as-is so the rest of the application stays responsive. It will start a cascade of additional complaints around "well you fixed piece A, why is piece B hitching? I almost task killed it because I wasn't expecting a freeze after piece A was addressed."

There are plenty of other glaring issues to address and new features to implement that won't be as bug prone as a developer new to asynchronicity will experience.

[Weissrolf]

The issue here is that the rendering thread is stuck doing processing.
The rendering thread should not be stuck doing processing. At this point the modules and extensions are loaded and processed, which should absolutely be done in its own thread(s).


[11/20/2020 10:51:49 AM] MEASURE: RULESETS LOAD - 6.4274138 - PFRPG2
[11/20/2020 10:51:49 AM] MEASURE: EXTENSIONS LOAD - 0.5778687 - 18
[11/20/2020 10:51:51 AM] MEASURE: MODULE LIST BUILD - 1.2745536 - 30
[11/20/2020 10:51:51 AM] MEASURE: REFRESH IMAGE ASSETS - 0.0399868
[11/20/2020 10:51:51 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0129954
[11/20/2020 10:51:51 AM] MEASURE: REFRESH TOKEN ASSETS - 0.0480212
[11/20/2020 10:51:51 AM] MEASURE: ASSET LIST BUILD - 0.1019733
[11/20/2020 10:51:52 AM] MEASURE: LOAD - PART 1 - 9.5619795
[11/20/2020 10:51:52 AM] Loaded FreeType library version 2.10.2
[11/20/2020 10:51:53 AM] s''
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 1.5399278 - (SR) Drag N Drop
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.455098 - Age of Ashes AP 2 Cult of Cinders
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.014 - Age of Ashes Player's Guide
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.0049707 - Calendars
[11/20/2020 10:51:57 AM] MEASURE: MODULE LOAD - 1.6023125 - Pathfinder Advanced Player's Guide
[11/20/2020 10:52:00 AM] MEASURE: MODULE LOAD - 3.3044129 - PF2 Bestiary
[11/20/2020 10:52:05 AM] MEASURE: MODULE LOAD - 4.6097339 - Pathfinder Second Edition Core Rules
[11/20/2020 10:52:05 AM] RULESET: Pathfinder RPG Second Edition ruleset v3.3.11 (PF2 release 17e) for Fantasy Grounds
Copyright 2020 Smiteworks USA, LLC
[11/20/2020 10:52:05 AM] RULESET: Core RPG ruleset v3.3.12A for Fantasy Grounds
Copyright 2019 Smiteworks USA, LLC
[11/20/2020 10:52:05 AM] EXTENSION: PFRPG2 Better Save Descriptions v0.2.\rCopyright 2020 Smiteworks USA, LLC.
[11/20/2020 10:52:05 AM] EXTENSION: Extension (Calendar Plus) loaded.
[11/20/2020 10:52:05 AM] EXTENSION: Express Yourself v0.4\rCreated by DIE Hard Gaming\r\nUse '/ey ?' for instructions.\r\nMore great resources at \r\(LINK)
[11/20/2020 10:52:05 AM] EXTENSION: (LINK)\rPFRPG Time Manager v1.2:\rThis extension is a GM tool which provides an interface for easy time tracking and management.\nThis extension is heavily-based on Clock Adjuster which is the work of pr6i6e6st.
[11/20/2020 10:52:05 AM] EXTENSION: Formation Graphics by DIE Hard Gaming. \r\nMore great resources at \r\(LINK)
[11/20/2020 10:52:05 AM] EXTENSION: Additional Golarion Languages and Fonts v1.0.1 by Trenloe and Callum for Fantasy Grounds v3.1.3+. \rCopyright 2015 Smiteworks USA, LLC.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Height) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Remove Effect Tag) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Overlays PF2) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Spell Tokens v2.0\r\n
[11/20/2020 10:52:06 AM] EXTENSION: CT Open on Turn v4
[11/20/2020 10:52:06 AM] EXTENSION: Dice Color Changer v1.0
[11/20/2020 10:52:06 AM] EXTENSION: Roboto Font Extension v1.1
[11/20/2020 10:52:06 AM] EXTENSION: ReadyCheck - Extension v1.3\rCoreRPG version for Fantasy Grounds\r--by Celestian 2018.02.28
[11/20/2020 10:52:06 AM] EXTENSION: CoreRPG - Single Window version 1.0.\rby Celestian, 2019
[11/20/2020 10:52:06 AM] EXTENSION: Thème L'Etoile Perdue pour Fantasy Grounds par Sasmira \nLast update : 27.04.2020.
[11/20/2020 10:52:06 AM] EXTENSION: CoreRPG - Party Item Identified v1.0\nFor Fantasy Grounds v3.3+\nBy Llisandur
[11/20/2020 10:52:06 AM] EXTENSION: Zuilin's Map Buttons and Trackpad Assistant v1.0\r\nfor FGU
[11/20/2020 10:52:06 AM] MEASURE: LOAD - PART 2 - 14.4312029

That's 24 seconds of the screen being frozen while a few megabytes of data are being processed, all modules loaded/processed by a single-thread. During that time Total War: Warhammer 2 processes several gigabytes of data. Compressing the whole Extensions folder into a single ZIP file takes less than 2 seconds on my PC.

I understand that this is a limitation of LUA, as is well demonstrated when World of Warcraft is loading its addon LUA scripts. But at least WoW manages to keep its UI rolling.


Multi-threaded UI is a misnomer. There is only one render thread, after all, and it has to be synchronous because of the way the drawing is layered, and is therefore not multi-threaded.
I disagree. First of all, there is no need for having anything synchronous while modules and extensions are loaded. The UI thread draws a nice spinning wheel or bar and the work-threads do the loading/processing in the background. And during game-play any CPU heavy processing that drops FPS could be done asynchronously in its own thread (unless the overhead negates the advantages).


Multi-threading doesn't come for free "even in 2020". It requires appropriate forethought, planning, and architecture. It isn't the kind of thing that is easy to add in retrospect, and it isn't the kind of thing that just happens without intent.
Which makes this such a tragedy to begin with. FGU has only just been published and was announced as a complete "rebuild from the ground up".


Creating parallel (multi-core) or multi-threaded (same core, different thread) in Unity wouldn't be trivial for this kind of app. If the developers already knowledgeable about how to use parallel processing and multi-threading then learning how to do it in Unity really isn't a good place to start.
Then maybe something like QT should have been used instead. I put thousands into computer parts and hundreds into Fantasy Grounds. As a result I would like my hardware to be used to its capacity and not sit around twiddling thumbs waiting while most of the system is idle.

[damned]

The rendering thread should not be stuck doing processing. At this point the modules and extensions are loaded and processed, which should absolutely be done in its own thread(s).


[11/20/2020 10:51:49 AM] MEASURE: RULESETS LOAD - 6.4274138 - PFRPG2
[11/20/2020 10:51:49 AM] MEASURE: EXTENSIONS LOAD - 0.5778687 - 18
[11/20/2020 10:51:51 AM] MEASURE: MODULE LIST BUILD - 1.2745536 - 30
[11/20/2020 10:51:51 AM] MEASURE: REFRESH IMAGE ASSETS - 0.0399868
[11/20/2020 10:51:51 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0129954
[11/20/2020 10:51:51 AM] MEASURE: REFRESH TOKEN ASSETS - 0.0480212
[11/20/2020 10:51:51 AM] MEASURE: ASSET LIST BUILD - 0.1019733
[11/20/2020 10:51:52 AM] MEASURE: LOAD - PART 1 - 9.5619795
[11/20/2020 10:51:52 AM] Loaded FreeType library version 2.10.2
[11/20/2020 10:51:53 AM] s''
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 1.5399278 - (SR) Drag N Drop
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.455098 - Age of Ashes AP 2 Cult of Cinders
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.014 - Age of Ashes Player's Guide
[11/20/2020 10:51:55 AM] MEASURE: MODULE LOAD - 0.0049707 - Calendars
[11/20/2020 10:51:57 AM] MEASURE: MODULE LOAD - 1.6023125 - Pathfinder Advanced Player's Guide
[11/20/2020 10:52:00 AM] MEASURE: MODULE LOAD - 3.3044129 - PF2 Bestiary
[11/20/2020 10:52:05 AM] MEASURE: MODULE LOAD - 4.6097339 - Pathfinder Second Edition Core Rules
[11/20/2020 10:52:05 AM] RULESET: Pathfinder RPG Second Edition ruleset v3.3.11 (PF2 release 17e) for Fantasy Grounds
Copyright 2020 Smiteworks USA, LLC
[11/20/2020 10:52:05 AM] RULESET: Core RPG ruleset v3.3.12A for Fantasy Grounds
Copyright 2019 Smiteworks USA, LLC
[11/20/2020 10:52:05 AM] EXTENSION: PFRPG2 Better Save Descriptions v0.2.\rCopyright 2020 Smiteworks USA, LLC.
[11/20/2020 10:52:05 AM] EXTENSION: Extension (Calendar Plus) loaded.
[11/20/2020 10:52:05 AM] EXTENSION: Express Yourself v0.4\rCreated by DIE Hard Gaming\r\nUse '/ey ?' for instructions.\r\nMore great resources at \r\(LINK)
[11/20/2020 10:52:05 AM] EXTENSION: (LINK)\rPFRPG Time Manager v1.2:\rThis extension is a GM tool which provides an interface for easy time tracking and management.\nThis extension is heavily-based on Clock Adjuster which is the work of pr6i6e6st.
[11/20/2020 10:52:05 AM] EXTENSION: Formation Graphics by DIE Hard Gaming. \r\nMore great resources at \r\(LINK)
[11/20/2020 10:52:05 AM] EXTENSION: Additional Golarion Languages and Fonts v1.0.1 by Trenloe and Callum for Fantasy Grounds v3.1.3+. \rCopyright 2015 Smiteworks USA, LLC.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Height) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Remove Effect Tag) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Extension (Overlays PF2) loaded.
[11/20/2020 10:52:06 AM] EXTENSION: Spell Tokens v2.0\r\n
[11/20/2020 10:52:06 AM] EXTENSION: CT Open on Turn v4
[11/20/2020 10:52:06 AM] EXTENSION: Dice Color Changer v1.0
[11/20/2020 10:52:06 AM] EXTENSION: Roboto Font Extension v1.1
[11/20/2020 10:52:06 AM] EXTENSION: ReadyCheck - Extension v1.3\rCoreRPG version for Fantasy Grounds\r--by Celestian 2018.02.28
[11/20/2020 10:52:06 AM] EXTENSION: CoreRPG - Single Window version 1.0.\rby Celestian, 2019
[11/20/2020 10:52:06 AM] EXTENSION: Thème L'Etoile Perdue pour Fantasy Grounds par Sasmira \nLast update : 27.04.2020.
[11/20/2020 10:52:06 AM] EXTENSION: CoreRPG - Party Item Identified v1.0\nFor Fantasy Grounds v3.3+\nBy Llisandur
[11/20/2020 10:52:06 AM] EXTENSION: Zuilin's Map Buttons and Trackpad Assistant v1.0\r\nfor FGU
[11/20/2020 10:52:06 AM] MEASURE: LOAD - PART 2 - 14.4312029

That's 24 seconds of the screen being frozen while a few megabytes of data are being processed, all modules loaded/processed by a single-thread. During that time Total War: Warhammer 2 processes several gigabytes of data. Compressing the whole Extensions folder into a single ZIP file takes less than 2 seconds on my PC.

I understand that this is a limitation of LUA, as is well demonstrated when World of Warcraft is loading its addon LUA scripts. But at least WoW manages to keep its UI rolling.


I disagree. First of all, there is no need for having anything synchronous while modules and extensions are loaded. The UI thread draws a nice spinning wheel or bar and the work-threads do the loading/processing in the background. And during game-play any CPU heavy processing that drops FPS could be done asynchronously in its own thread (unless the overhead negates the advantages).


Which makes this such a tragedy to begin with. FGU has only just been published and was announced as a complete "rebuild from the ground up".


Then maybe something like QT should have been used instead. I put thousands into computer parts and hundreds into Fantasy Grounds. As a result I would like my hardware to be used to its capacity and not sit around twiddling thumbs waiting while most of the system is idle.

I think you have previously mentioned your lack of coding experience and yet you write these replies with such authority?

[Weissrolf]

You quoted my whole post, just to derail the discussion towards my personality? Why would you do that? Is this part of the etiquette on this forum?

I do know coding (but not algorithms and the specific details of most coding languages), but even more so I know computing and computers. Testing drivers, software and hardware is part of my job. That being said, please don't turn this thread into a discussion about me. Stay on topic.

[Trenloe]

Moved to The Tavern forum as this is a general discussion about Fantasy Grounds, this is not a support issue and so shouldn't reside in the House of Healing. Please post only technical support issues in the House of Healing forums. Thanks.

[Weissrolf]

Fair enough. One should consider, though, that *all* of my players and other FG users thought FGU to be frozen/crashed due to this mechanism. I actively have to keep my players from shutting down FGU to restart it, because whenever someone sees "not responding" and grayed out UI they deem an application crashed.

One could consider to call the latter a support case and problem that needs to be fixed. Anyway, suffering GUI freezes directly relates to the lack of multi-threading, so without one we won't see a fix for the other.

[Trenloe]

Fair enough. One should consider, though, that *all* of my players and other FG users thought FGU to be frozen/crashed due to this mechanism. I actively have to keep my players from shutting down FGU to restart it, because whenever someone sees "not responding" and grayed out UI they deem an application crashed.

One could call absolutely call this a support case and problem that needs to be fixed.
A specific issue with logs etc. is absolutely a support case. A generic discussion, with lots of hypotheses and guesses as to how FGU really works, might work and should work is not a support case. It wastes the time of those who are trying to work on actual support cases.

[Weissrolf]

I am not guessing, I am monitoring threads directly, it's no rocket science with tools like Process Explorer.

Given the current design the "not responding" issues don't seem to be solvable, but of course I can gladly open up a proper support case for "not responding" issues with logs, screenshots, thread analysis and everything. I have no beef here.

[Moon Wizard]

Due to the way rulesets have full control over display of all aspects of the tabletop and that information is handled in the main thread through a Lua engine, your best bet is to reduce the amount of material loaded in your campaign to improve performance. If you have every module ever created for say the 5E ruleset open in FGU, it's going to slow down the UI. Close the ones you don't need open.

Regards,
JPG

[Weissrolf]

Thanks for chiming in, well appreciated.

Both rulesets and extensions do not have to be loaded by the main thread, though, even when they need to run in the main thread. FGU proves that itself, because the everything loaded as "Load Part 1" is not loaded by the main thread. So no problem keeping the UI alive and displaying a busy animation via main thread.

Then I wonder what "LUA engine" means? I assume that the LUA scripts are not interpreted but compiled by a JustInTime compiler? Does that compilation of multiple scripts/ruleset/extension files have to be done in sequence by a single thread?


Due to the way rulesets have full control over display...
What way is this? Could the way maybe be changed? Judging by another big software title I suspect not (so easily):

World of Warcraft suffers from the very same problems. My 170 LUA addons scripts are all loaded by one main thread and then run by the WOW main thread.

The latter (run) can lead to a script causing massive FPS drops down to a complete halt. There are lots of extra threads running alongside the main thread, though, putting all kinds of extra load on other cores (mainly GPU/output related stuff I suspect, have to switch back from DX12 to DX11 to check).

The former (load) is solved differently compared to FG. What WOW does is that after each (or maybe a bunch) of scripts are loaded it updates the UI to fill the progress bar a bit and respond to the OS. It's jumpy, there are massive fps drops in between (from 1200 to 0), but it keeps the process responding and gives the user a sense of progress.

[Jiminimonka]

Thanks for chiming in, well appreciated.

Both rulesets and extensions do not have to be loaded by the main thread, though, even when they need to run in the main thread. FGU proves that itself, because the everything loaded as "Load Part 1" is not loaded by the main thread. So no problem keeping the UI alive and displaying a busy animation via main thread.

Then I wonder what "LUA engine" means? I assume that the LUA scripts are not interpreted but compiled by a JustInTime compiler? Does that compilation of multiple scripts/ruleset/extension files have to be done in sequence by a single thread?


What way is this? Could the way maybe be changed? Judging by another big software title I suspect not (so easily):

World of Warcraft suffers from the very same problems. My 170 LUA addons scripts are all loaded by one main thread and then run by the WOW main thread.

The latter (run) can lead to a script causing massive FPS drops down to a complete halt. There are lots of extra threads running alongside the main thread, though, putting all kinds of extra load on other cores (mainly GPU/output related stuff I suspect, have to switch back from DX12 to DX11 to check).

The former (load) is solved differently compared to FG. What WOW does is that after each (or maybe a bunch) of scripts are loaded it updates the UI to fill the progress bar a bit and respond to the OS. It's jumpy, there are massive fps drops in between (from 1200 to 0), but it keeps the process responding and gives the user a sense of progress.

WOW is a completely different engine to Unity and has completely different requirements. Also WOW is a BILLION dollar game with 16 years of super high funding and literally hundreds of people working on it at its peak. Even a team that big had problems ironing out the millions of lines of code that contained bugs and errors. It took them 5 years to figure out how to fix latency issues with spell casting (and it still has issues)

Do a C++ programming course and learn how coding works. I used to back in the 1980's (in assembly, not C) - A piece of code that runs perfectly when you step thru it line by line often doesn't do as expected when its running and takes hours to figure out.

With a massive program like FGU getting the basics up and running first are the priority, then bug fixing and streamlining occur - which then create new bugs which need to be fixed (and that is why sometimes things get rolled back).

Also even though multi-core CPUs have been around for a long time now, the mindset of many programmers is still "one thing at a time" because humans brains work that way - and until software or hardware automatically allocates threads at run time, it will be an issue for a while yet.

[LordEntrails]

I think this thread proves a few things. One is that the developers know the limitations of the software in regards to processing bottlenecks. Two, that they intend to improve upon such limitations as reasonable business decisions dictate. And three, that further developer involvement on this topic simple takes time away from them actually developing improvements to the software.

[Jiminimonka]

I think this thread proves a few things. One is that the developers know the limitations of the software in regards to processing bottlenecks. Two, that they intend to improve upon such limitations as reasonable business decisions dictate. And three, that further developer involvement on this topic simple takes time away from them actually developing improvements to the software.

Agreed.

[Weissrolf]

So everyone is cool with showing "not responding" instead of updating a simple progress bar? This does not even need multi-threading to be improved. The same "not responding" (or at least blue circle pointer) thing happens when very large images are opened (plus memory usage skyrockets), or when larger modules are loaded. FGU keeps freezing far too often.

You really need to think out of your own veterans' box sometimes. I brought 8 new players to FG and all of them had to be handheld to either properly install FG or at least not be fooled into thinking the application froze (and thus try kill the process to restart). These are serious roadblocks for software trying to reach a new audience.

And yes, people hope for a modern architecture underneath a responsive UI when they buy new software in 2020.

[Sulimo]

I think part of the problem is that not everyone sees 'not responding' or the spinning wheel when using FGU.

I know I do not see that. Maybe a couple of times early in the Beta, but not for a long time. My players do not see that either.

Perhaps check what you are loading (extensions?) and see if one (or more) of them has not yet been optimized for FGU. I know that was a problem with some of them, and most of the extension devs were waiting until full release to update their extensions.

I believe I recall a discussion about images and memory usage somewhere on the forums, but I do not have the link handy.

[Griogre]

Personally I don't like not responding. For the record, reasonable and meaningful progress bars are hard if you don't know how long the process is going to take or the number of files to be loaded, ect - which is likely here since you are waiting for your clients to download across the Internet. I would settle for a spinner circle.

The easiest way to get rid of the lag would be to stop support for extensions and scripting, which would ruin the ability to have community add ons. I don't think people like the "Not responding", I think they like their add-ons more than they dislike the non responding - which is usually just once a game at the start or if the GM shares large assets.

[celestian]

The easiest way to get rid of the lag would be to stop support for extensions and scripting

There are certainly some extensions that might do a lot of "loading" of data for processing whatever they do but I can tell you that that's not the "easiest" way to fix the problem because... they are not the problem. What takes the longest is loading all the data modules. i.e. books, content/etc. I suspect that reason is because of LUA objects for said data... thats a guess based on what I've heard over the years from JPG. While some extensions might also process some of that same data the bulk of them dont and simply removing them does not actually fix the problem.

[Griogre]

The ability to use LUA at all or any scripting instead of just hard coding the data modules as dlls it is a root cause of the bottleneck in my opinion. When I said extensions I didn't just mean the add on extensions I meant the XML ruleset templates and scripts as well. To FG there isn't any real difference between a ruleset, an extension, a library module, or a campaign module - they are just XML data files.

Using XML at all to hold data is a performance hit, you have to read it from file, make sure its well formed and then load it into memory. FG's XML parser and /or the ruleset templates also do some processing by filling in missing XML data with defaults.

Traditionally you take that performance hit to gain the flexibility of allowing 3rd parties to safely modify the behavior of your base engine code. I think this is a worthwhile trade for this type of application.

I think if you were to compile the rulesets down to binary you would get a performance gain though I'm doubtful if it would beat just converting *every* FG art asset to 256 colors - it would be fun to profile. :p

[celestian]

The ability to use LUA at all or any scripting instead of just hard coding the data modules as dlls it is a root cause of the bottleneck in my opinion. When I said extensions I didn't just mean the add on extensions I meant the XML ruleset templates and scripts as well. To FG there isn't any real difference between a ruleset, an extension, a library module, or a campaign module - they are just XML data files.

Using XML at all to hold data is a performance hit, you have to read it from file, make sure its well formed and then load it into memory. FG's XML parser and /or the ruleset templates also do some processing by filling in missing XML data with defaults.

Traditionally you take that performance hit to gain the flexibility of allowing 3rd parties to safely modify the behavior of your base engine code. I think this is a worthwhile trade for this type of application.

I think if you were to compile the rulesets down to binary you would get a performance gain though I'm doubtful if it would beat just converting *every* FG art asset to 256 colors - it would be fun to profile. :p

There is certainly a performance consumption by such flexibility, however my comment was specifically directed at the method used to manage data with lua. Each data node is a lua object (JPG has mentioned this several times) and I am told that this is the largest issue with resource consumption. For example if you try and create 1000 data nodes of even a most simplistic nature it will more than likely cause the system to choke completely. This is during a live session, after everything has loaded. I had to create a process to import a large data set specifically because of the issue. It's also why I had to re-write the CT for the 2E ruleset (DM side) due to the number of "nodes" within the data structure I went with.

The load times for xml conversion to information that the ruleset can use I believe is trivial, it's the data that is the key consumer of process time.

JPG has mentioned a few times he would like to uncouple LUA node/data but it would be a major re-write and break a lot of existing work so is not likely to happen anytime soon (or at all?).

I would be happy to have anything that would improve performance, as is I am hitting the top end of that at times myself. If multithreading would help, I would love it. I don't have the background deep enough to know if it would however.

[Griogre]

Well now we have Unity we can hope FGU might eventually move from LUA to C#... My loathing for LUA globals is real. :)

I'm not that up on multi-threading either but I have read they are starting to get to decent general purpose algorithms for CPU load balancing which would help.

[Jiminimonka]

I propose a solution to help those people who assume the software has locked up if they can't see a little progress bar or whatever.

Do what Discord does. Have some random messages pop up:

Acquiring parchment
Taming dragons
Getting Xanathars stamp of approval

Etc. On the loading screen.

I have 7 players all of them fairly new to Fantasy Grounds and none of them thought it locked up. But I did say it rakes a while for the table to load. Time to get a drink and snacks for game time.

But a random. message might help.

[Valyar]

What I am mostly interested and really need is SW to improve the loading times... at the moment Unity loads fresh or during /reload twice or three times slower which makes developing new content very very slowly when you need to test pixel-based adjustment or other fine-tuning activities.

There is no quality of life improvement for developers at all. So any change towards this - I am all game.

[Moon Wizard]

Reducing the amount of content is always helpful. If you have thousands and thousands of files in your images/tokens/portraits directory; start up times will always be slower as they are indexed at session startup.

Regards,
JPG

[Weissrolf]

- Are non-changing files indexed? or are hashes used to only index files that need new indexing?

- Is indexing of multiple files done concurrently via multiple CPU cores/threads?

- How can I disable images from rulesets? I own the Pathfinder 2 Core RPG module, which is full of images I hardly ever use and always spam my image browser dialog. How can I turn these off while still using the ruleset?

[DM_BK]

I'd also love a LUA to C# change ... though I don't actually expect to see that happen...nice thing to wish for.

Start up times with FGU are crazy long. Definitely some room for some optimizes in that area.

[Jiminimonka]

I'd also love a LUA to C# change ... though I don't actually expect to see that happen...nice thing to wish for.

Start up times with FGU are crazy long. Definitely some room for some optimizes in that area.

C# is windows only as far as I know - so no mac or linux.

[Griogre]

Mono is open source and makes C# cross platform (though admittedly without the latest .NET bells and whistles).

However, the important thing here it that C# is the scripting language used by Unity and Unity is cross platform. So it wouldn't really matter how cross platform stand alone C# is since its Unity that compiles the different platform exes.

[Weissrolf]

The long startup-times are not directly connected to the multi-threading vs. single-thread discussion, though. From Launcher already running to starting a campaign FGU takes 50% longer for GMs and 100% longer for players compared to FGC.

FGC is just as single-threaded as FGU in all of this (maybe even more), but still dramatically faster for loading campaigns (same modules, same extensions, same files, same everything).

So even if multi-threading might help with load-times, something seems to lack optimization with FGU that multi-threading alone might not solve. Still maxing out only 1 out of 16 threads while making me wait for "not responding" feels wrong.

[bmos]

I propose a solution to help those people who assume the software has locked up if they can't see a little progress bar or whatever.

Do what Discord does. Have some random messages pop up:

Acquiring parchment
Taming dragons
Getting Xanathars stamp of approval

Etc. On the loading screen.Classic has this!!
I asked if it was planned to come to Unity and never got a reply.
It's even better because it teaches you FG, a couple tips at a time.
https://www.fantasygrounds.com/forums/showthread.php?61306-Loading-Screen-Tutorial-Messages

[Jiminimonka]

Thats all it needs until the code is optimised - which is obviously the devs know and are working on. As well as adding features and expanding way beyond what FGC was able to do.

I play twice a week with 7 people connecting to my table and I've never had one of them complaining or thinking it crashed. Some of them are under 25 years old and some of them old like me and even older.

[bmos]

Thats all it needs until the code is optimised - which is obviously the devs know and are working on. As well as adding features and expanding way beyond what FGC was able to do.

I play twice a week with 7 people connecting to my table and I've never had one of them complaining or thinking it crashed. Some of them are under 25 years old and some of them old like me and even older.Want to trade players? ;)
I kid, but mine definitely have been confused many times by hangs and load times. Impatience with tech is a very common pattern I see (I run an IT support company).

[Jiminimonka]

Want to trade players? ;)
I kid, but mine definitely have been confused many times by hangs and load times. Impatience with tech is a very common pattern I see (I run an IT support company).

Oh I feel for you... Q: "my computer isn't working" A: "have you plugged it in?"....

[Weissrolf]

Impatience with tech is a very common pattern I see (I run an IT support company).
I am mostly guilty of impatient with software not making use of expensive hardware and modern design paradigms. We are still in the digital stone-ages on many fronts.

I do IT support and driver development testing and application vs. drivers vs. hardware testing, I know all the big and little pitfalls. I know end-users and I know developers (and support in between), both of which often don't interconnect. But for commercial software I am willing to give more slack to end-users, because they are the ones paying the bills. Community developers develop for themselves and the betterment of the community, once you ask for money you take up responsibility for working with end-users, for better or worse.

When a developer states something like "we have done it this way for over 10 years" as a rationale for not consider change then I know not to spend more energy into giving feedback to their product.

My players do not seem to be enticed to shell out money on FGU for the time being, though, especially with me using an Ultimate license (FGC + FGU) and buying all the modules. So they have to live with what they get and be happy about FG still being better than many other products. They are not customers and as such not entitled to request improvements. When improvements happen, they happen, when not then maybe something else comes along in the long run, they won't lose money anyway.

[Jiminimonka]

FG is better than any other VTT product out there.

The way its made extendible also is a feature. If you want change something you can make an extension to change things. If there is a big demand for an extension eventually it gets added (look thru the extension threads and see how many are deprecated because they are part of core functionality now).

Opinions of course are like, opinions.

[Kelrugem]

When a developer states something like "we have done it this way for over 10 years" as a rationale for not consider change then I know not to spend more energy into giving feedback to their product.

I think I know to which thread you refer, but then I have to say that this was not the argument :) A developer had good reasons for something and just said that this concept and these reasons did not change in the last 10 years :) That is something different, the 10 years served as emphasis. So, the reasons where the rationale, not the time how long FG handles something :)

[Weissrolf]

You also need to remember that Unity API is not Thread-safe, so all calls to Unity API should be done from the main Thread.
Ouch. Does FGU do rather many or rather few Unity API calls?

[Moon Wizard]

All UI display must go through main thread in order to be displayed in Unity; which is what allows full cross-platform builds.

Regards,
JPG

[Weissrolf]

So could you use the main thread for UI output and other threads (or one combined 2nd thread) for everything not directly connected to UI output?

You already use a second thread for "LOAD PART 1" anyway, so please try to keep the main UI thread alive to display some kind of progress instead of having it lock up. Also consider doing "LOAD PART 2" on its own thread while the main UI thread remains animated.

When players load/unload a module, consider doing the loading in its own thread and keep the main UI thread alive/responsive.

We users also keep wondering if ionger load-times are because of missing optimizations or because of Unity (bloat)? Or rather, can we even hope for more optimizations or is this it with Unity/FGU? Loading the very same PF2 CRB module takes 1-2s in FGC, but 6-7s in FGU (+UI freezes).

[fubeca150]

All UI display must go through main thread in order to be displayed in Unity; which is what allows full cross-platform builds.

I was getting on to post this same thing. You already told us exactly what the problem was a few pages ago, but I'll expound so-as to not take more dev time in this thread.


Render thread is always single-threaded in every UI framework, including QT, C# WPF, Xamarin, and other game engines. This is the case because UI is built with a layered approach and you can't just have things render in any old order or else you get all kinds of weird display artifacts. In the case of FGU, this is based on information coming from the LUA engine once the main playing area is displayed. The initial load of FGU from the launcher shows a progress bar because at that point in time the LUA state machine can run in its thread, and the UI render thread doesn't care what the LUA state machine is doing -- yet. In the launching mode it would only care to know when the LUA engine is ready.

Once the transition to "the game" happens, everything has to come via the LUA engine because that's where all the state is. When you start loading modules, now you're in a state where your render thread is directly dependent upon the LUA engine, which is busy loading your module state and blocking further requests until it's done. That's why it goes white screen at that point, and white screen is just the OS specific way of letting you know the program isn't rendering or accepting input.

Going to another scripting engine isn't a solution when part of the problem is maintaining backwards compatibility, and most of the problem is contention over locked resources (in this case the LUA state engine). There will still be contention regardless of which scripting engine is used because if the UI is rendering incomplete state you get weird artifacts or crashes. This is one reason that immutable (or Frozen) state is what you want to work with in the UI layer (and arguably in as many places as possible but that claim sparks a religious debate). The state of stuff will be changing, of course, but it's changing elsewhere.

The way many of the UI rendering engines get away with threading for processing on something OTHER than the render thread is that they dispatch state changes to the UI layer. So while it appears that the program is responsive, it might not be doing anything useful other than placating the user by letting them know it's busy and not in the process of crashing.

In the case of FGU, though, even if you could figure out a way to create such a dispatcher between LUA and the Unity code layers, you still have a major problem to overcome, namely "exactly what am I supposed to dispatch?" FGU's rulesets, modules, and extensions have a ton of expression based stuff. Value1 = value2 * value3. So if Value3 changes, it needs to dispatch notice of anything that subscribes to it. Most game related expressions aren't that simple. Even calculating a character's main attributes is a series of expressions in an "all games supported" engine like FG, and everything else builds off of the results of those expressions.

Creating a dynamic subscription dispatcher is a lot of work to do to avoid hitching, and a very difficult architectural change. It's also pretty special case, so probably wouldn't be available on the Unity store. And it's also completely understandable why it would not be included in a complete rebuild of FG.

So far the only times I've seen noticeable hitching have been when opening a list (which is so much better now than it was a few months ago), when loading all the modules I want to use when setting up my campaign for the first time, and when players are connecting. I can live with the loading of modules thing because I only need to do it the one time, and I never toggle it while players are connected. All the players will experience the same hitching on their end when they activate the modules for the first time, but again I only hear them complain about "the steps" whenever we start a new campaign. My group might be rare in that it's usually punctual, so we don't even have to deal with the player connection hitching except at the beginning of the session.

[mm44]

one simple solution is to limit the amount of layers in you maps.. and if it gets really bad.. turn off things like Fx, and LOS. You can just use the original version of fog of war and reveal the maps as players explore..

[Weissrolf]

I was getting on to post this same thing. You already told us exactly what the problem was a few pages ago, but I'll expound so-as to not take more dev time in this thread.
Thanks for the thorough explanation!


Render thread is always single-threaded in every UI framework, including QT, C# WPF, Xamarin, and other game engines.
Not a problem as long as other tasks than rendering can be sourced to different threads.


In the case of FGU, this is based on information coming from the LUA engine once the main playing area is displayed.
We welcome FPS drops (aka energy-saving) when nothing happens. We can live with fps drops when something is calculated. We don't like input/output freezing to 0 fps, though.


The initial load of FGU from the launcher shows a progress bar because at that point in time the LUA state machine can run in its thread, and the UI render thread doesn't care what the LUA state machine is doing -- yet.
I assume this is "LOAD PART 1" then, where a mono thread is doing the work?!


In the launching mode it would only care to know when the LUA engine is ready.
When is this mode entered with FGU? After PART 1 and before PART 2?


Once the transition to "the game" happens, everything has to come via the LUA engine because that's where all the state is.
Is this where PART 2 begins and modules are loaded by the main thread?


When you start loading modules, now you're in a state where your render thread is directly dependent upon the LUA engine, which is busy loading your module state and blocking further requests until it's done.
In FGU the "render thread" is the same as the "LUA engine" thread. Do both have to run in the same thread with Unity? The LUA engine cannot do its thing in its own thread while the main thread remains animated? Digital stone ages, but let's assume from this point on that this is the case.

So the rendering pipeline waits for the LUA engine to give feedback. Why does the LUA engine not do this? I know it is busy loading and processing scripts, but how expensive can it be to sent a short ping to the rendering engine every once in a while?


That's why it goes white screen at that point, and white screen is just the OS specific way of letting you know the program isn't rendering or accepting input.
Of course this is the OS trying to make sense of it. It begins with a blue circle mouse-pointer animation, then turns into a white screen and finally into a "not responding" message. All defined by timeouts set within the OS.


Going to another scripting engine isn't a solution when part of the problem is maintaining backwards compatibility, and most of the problem is contention over locked resources (in this case the LUA state engine).
And here we get to the point where single-thread design is not the main culprit. FGU's blatant slowness compared to FGC when loading the very same LUA scripts is. Why would the same LUA module take 1-2 seconds to load in FGC, but 6-7 seconds to load in FGU (including a short output freeze)? If this was better optimized then we wouldn't have to think too much about multi-threading anything script-loading related.


This is one reason that immutable (or Frozen) state is what you want to work with in the UI layer (and arguably in as many places as possible but that claim sparks a religious debate).
If the rendering and LUA engines cannot be handled asynchronously in different threads then the LUA engine should work in a way that keeps the UI responsive. This will introduce cost, hopefully not too much, though. But again the possible solution also suffers from the current lack of optimization to bring FGU to at least match FGC. Opening an image allocates to much (more) private memory in FGU that I am not surprised that so many more CPU cycles are necessary to handle these thing. All that extra data wants to be processed.


The way many of the UI rendering engines get away with threading for processing on something OTHER than the render thread is that they dispatch state changes to the UI layer. So while it appears that the program is responsive, it might not be doing anything useful other than placating the user by letting them know it's busy and not in the process of crashing.
Which is important. Even back in the days of DOS applications kept the cursor animated to announce to users that they did not freeze. We still have animated hour-glasses, circles and beachballs to that effect. And there is a reason why keyboards come with an input buffer to allow users further input even when the data cannot be processed immediately.


In the case of FGU, though, even if you could figure out a way to create such a dispatcher between LUA and the Unity code layers, you still have a major problem to overcome, namely "exactly what am I supposed to dispatch?"
Drawing character sheets/windows and anything that does not need further expressions calculations would be a start. The missing numbers can be filled out once they are finished being calculated. Instead of monolithically displaying everything in one go there always is the option of displaying things progressively.


FGU's rulesets, modules, and extensions have a ton of expression based stuff. Value1 = value2 * value3. So if Value3 changes, it needs to dispatch notice of anything that subscribes to it. Most game related expressions aren't that simple. Even calculating a character's main attributes is a series of expressions in an "all games supported" engine like FG, and everything else builds off of the results of those expressions.
But are these expressions and the calculations behind it really expensive? Character sheet based stuff seems like very simple math with small numbers to me. We are not talking calculating 3D raytracing rendering scenes here.


Creating a dynamic subscription dispatcher is a lot of work to do to avoid hitching, and a very difficult architectural change. It's also pretty special case, so probably wouldn't be available on the Unity store. And it's also completely understandable why it would not be included in a complete rebuild of FG.
I would think that a rebuild is just the opportunity to design these kind of things from the ground up, instead of trying to tack them on later. It also seems that you are telling me that modern UI frameworks do not come with readily available tools to set this up?! Quite a shame.


So far the only times I've seen noticeable hitching have been when opening a list (which is so much better now than it was a few months ago), when loading all the modules I want to use when setting up my campaign for the first time, and when players are connecting.
I am on a strong 9900K based computer, but still see dropouts happening, mostly shorter than the "not responding" timeout. Waiting for one-time load stuff is fine by me, although I am still unhappy that performance is so much worse compared to FGC for doing the same things. It's the in-between short drops in responsiveness that make the experience less pleasant.

And then there is the regular dropouts when new features like LoS are used. This is something where Moon Wizard stated that they are considering multi-threading for the calculations of LoS. I would welcome this.

Then again, he also stated that networking is already multi-threaded, but I still got up to half a minute delays when starting Launcher, because the whole UI was waiting for networking to answer. Instead the UI should have started and told me in a meaningful way that networking is still busy doing its thing. These are design/concept problems that come before the code and UI framework hurdles. It sometimes seems as if the developers forget that there are people in front of their expensive computer hardware waiting to get information about what the heck is going on and whether they should rather get a hot drink meanwhile.

[Weissrolf]

one simple solution is to limit the amount of layers in you maps.. and if it gets really bad.. turn off things like Fx, and LOS. You can just use the original version of fog of war and reveal the maps as players explore..
So effectively going back to FGC, because from a player's perspective these are the main incentives to even use FGU. Not to mention the GM who was happy to get rid of having to manually unmask the map.

Network transfer is worlds apart quicker in FGU compared to FGC, but players usually don't experience so much of that part when processing the transferred data takes so much longer instead.

[Jiminimonka]

I can live with a half minute delay here and there (and longer because a minute is only a long time when you stare at a clock) while FGU is optimised and has features added (which is what sets FGU apart from FGC, its going to get more stuff, LOS being just the start), and being as I am not an expert in writing computer software because I have not done so for over 25 years, I will leave it to people who write and fix code all day to do their job, and let them deal with bug reports.

[fubeca150]

I agree that giving some kind of progress indicator would address the perception issue. The solution is a lot more difficult than you make it out to be, though. I'd love to see it addressed, but not at the cost of features that matter more to me. From what a few others have chimed in, that's the same position others hold.

I'm on vacation right now, which is why I can spend so much time conjecturing and thinking about this. Plus I feel bad about dog-piling early in this thread now that I've given it a lot more thought and realized the scope of necessary changes.

I'm very bad at forum quoting, so I'm going to give it a try.


In FGU the "render thread" is the same as the "LUA engine" thread. Do both have to run in the same thread with Unity? The LUA engine cannot do its thing in its own thread while the main thread remains animated? Digital stone ages, but let's assume from this point on that this is the case.

They aren't in the same thread. LUA runs on its own thread, but based on what Moon Wizard said, the "how to draw" comes from LUA, and that will be because FGU maintained backwards compatibility with FG. This is a very complicated problem to work around.


So the rendering pipeline waits for the LUA engine to give feedback. Why does the LUA engine not do this? I know it is busy loading and processing scripts, but how expensive can it be to sent a short ping to the rendering engine every once in a while?

I appreciate the complexity of the pickle they've gotten themselves into. 15 years ago this was still commonplace in applications, and it wasn't until mobile applications hit it big that people started to demand a better experience than being happy to just have something that works.

Here's the pickle of the solution you suggested. LUA engine is busy loading a module. If they were to add a ping in that process, then the ping would go out to the Unity engine, and then need to be dispatched to a thread that cares. That thread happens to be the render thread. The render thread is waiting on the LUA thread, and now the LUA thread is waiting on the render thread. That's a deadlock.

Okay, so let's say they fire and forget the ping to avoid deadlocking the render and LUA threads. Now the ping goes out to the dispatcher. The dispatcher will wait until the render thread can pick it up. The render thread will pick that up as soon as the LUA thread gives it the information it's currently waiting on. As soon as it gets a chance to continue on it will process a bunch of those pings all in a row. If you can remember back far enough, you might even remember software that used to do this. The software would be frozen and then all of a sudden it would refresh, then refresh again multiple times. That's those pings finally coming through.


If the rendering and LUA engines cannot be handled asynchronously in different threads then the LUA engine should work in a way that keeps the UI responsive. This will introduce cost, hopefully not too much, though. But again the possible solution also suffers from the current lack of optimization to bring FGU to at least match FGC.

LUA is a scripting engine and is UI framework independent. That developers hook a UI to it is incidental to LUA and none of its concern. That developers are using the LUA engine to dictate everything about the UI is the crux of the problem we're seeing.

The optimization is something that they can work on. And if optimization is sufficient then all the rest of the asynchronous stuff wouldn't need to be done. I'd bet they are working on the optimization, but a few guys can only do so much in a given timeframe. And judging on the patch notes that I read with each update, they are quite busy.


Even back in the days of DOS applications kept the cursor animated to announce to users that they did not freeze. We still have animated hour-glasses, circles and beachballs to that effect.

That's not the application that is animating the cursor. The applications that manage it send an operating system message to change the cursor prior to doing heavy work, and then when the work is done they send another message to revert it back. Thankfully that's mostly a thing of the past, and application developers that do it nowadays need to be taught a new thing or two. The operating system now does it when an application doesn't respond to message prompting from the OS.


Drawing character sheets/windows and anything that does not need further expressions calculations would be a start.

I had segued into a possible solution and was musing over the difficulties and complexities associated with that solution. Adding another layer to hold current "frozen" state is one possible solution to the problem. By adding a separate layer between the render layer and the LUA layer, the LUA layer could pump "pings" (as you put it) up to that layer and the pings would be of the nature of the new value of a given variable. Most applications can get away with pumping the fact that state changed and that's all that needs to happen. But pumping only that means that the receiver of the message would still need to go back to the LUA engine to get the actual changes. So that pump needs to be the state, too, not just that it changed.

The inherent problem with an approach of that nature in this case is that with an expression engine like what FG uses is dependent on many other things, and identifying what would need to be pumped up the ladder would take extra effort because when one value gets pumped the LUA layer would have to figure out all of the values dependent on value3, and on any values dependent upon those values. It's a tree. So now it would be pumping a ton of state all the time, and LUA isn't particularly speedy, either. (And the end result would be that it would take a lot longer to do any useful new processing.)


I would think that a rebuild is just the opportunity to design these kind of things from the ground up, instead of trying to tack them on later. It also seems that you are telling me that modern UI frameworks do not come with readily available tools to set this up?! Quite a shame.

It is a shame from the perspective of a consumer that is fixating on that, for sure.

I can only conjecture, especially because I'm a relative newcomer, but I think this would have added at least a couple of months of development work to their timeline as they experimented with different approaches. They wouldn't have done it early because they needed a proof of concept. Then they needed to get ready for a Kickstarter. Then they needed to get the bits that people used and notice all the time functional for release. This loading issue isn't one that constantly plagues every user. It's a startup issue, or an issue that happens when a user toggles modules on later.

Anyways, it's a super complicated problem and I don't see that there's a whole lot of bang for buck to solve it. I'll admit that I've never seen FG's code. I have, however, come into projects to solve similar issues, and it's a hairy issue. If optimization doesn't fix it, it's a hard sell to say "well, I guess we can rewrite".


It sometimes seems as if the developers forget that there are people in front of their expensive computer hardware waiting to get information about what the heck is going on and whether they should rather get a hot drink meanwhile.

Developers truly don't forget. People assume developers are nefarious and have all these plots about how to make peoples' lives miserable. It's actually quite the contrary. You might be surprised to learn that most developers want their users to have the best possible experience. They are frustrated in their desires by only having so much time to get stuff done. That means prioritizing tasks in an order that makes the most sense to the widest audience. Only open source projects can afford to stay in architecture mode for 4-5 years.

[Nylanfs]

Yep, PCGen has really only been re-written fully like twice in 20 years.

[Weissrolf]

I agree that giving some kind of progress indicator would address the perception issue. The solution is a lot more difficult than you make it out to be, though. I'd love to see it addressed, but not at the cost of features that matter more to me. From what a few others have chimed in, that's the same position others hold.
For our group FG is mainly a graphical user-interface for table-top heavy systems, we don't need it for something like Eclipse Phase, just for Pathfinder. All the automation is great and helps to lessen the GM's work, but we could just as much play with PDF files and roll on our table (or via Discord bot). FG's main task (for us) is to provide a good input/output experience, show a map + help visualize what everyone is doing. That doesn't mean that we don't immensely enjoy the automation, especially my players who did not have to pay a single dime for it. ;)


They aren't in the same thread. LUA runs on its own thread, but based on what Moon Wizard said, the "how to draw" comes from LUA, and that will be because FGU maintained backwards compatibility with FG. This is a very complicated problem to work around.
I think we mean different things here. You seem to mean the thread handling output to the GPU driver, that thread is hardly ever taxed even when frame-rates drop down to zero. I mean to have a thread dedicated only to GUI input/output with everything else (like dice rolling, stats calculations, expressions, etc) being handled by a thread independent of GUI I/O. Moon Wizard seems to suggest that this is not technically possible with Unity + LUA (for the time being). Bad luck then, but also another shackle to keep us in the digital stone-ages.


Here's the pickle of the solution you suggested. LUA engine is busy loading a module. If they were to add a ping in that process, then the ping would go out to the Unity engine, and then need to be dispatched to a thread that cares. That thread happens to be the render thread. The render thread is waiting on the LUA thread, and now the LUA thread is waiting on the render thread. That's a deadlock.
I did not get the impression that this is how it works. All heavy lifting is done by the main FGU thread, this seems to be where the LUA engine is situated and this is were all Unity API calls need to happen. So when the LUA engine is busy loading data from a drive and then process said data, the latter of which takes considerably longer than the former in FGU, then why would the loading routine not be able to give a ping back to its handler every X seconds/kb?

Let's assume that LUA methods and Unity API calls are not capable of processing anything else than loading a full file, then we could still at least keep the UI reactive in between multiple files being loaded and between loading and processing.


The optimization is something that they can work on. And if optimization is sufficient then all the rest of the asynchronous stuff wouldn't need to be done. I'd bet they are working on the optimization, but a few guys can only do so much in a given timeframe. And judging on the patch notes that I read with each update, they are quite busy.
Indeed, but judging by the current implementation I get the impression that there are (responsive) UI design issues to begin with, even before tackling final implementation.

Here is an example: I double-clicked on the "Campaign" image sub-folder and FGU began loading the images inside to display thumbnails. Not only does it not tell me what is going on, but it did not even make the jump to the sub-folder to show me that it accepted my double-click. Ignore the FPS being displayed at the top, the real fps is 0 (zero) and the screen goes white ("no response") if I click on FGU's window again.

https://i.imgur.com/rl1Z5xy.png

Every other thumbnails displaying software out there would open the folder, display the thumbnails that were already processed and then one by one display the ones that finished later. Some software even presents a progress indicator to show how far it got. FGU displays zilch until all images are read and ready to be displayed as thumbnails.

Feature request: Please implement a thumbnail cache for assets and overhaul the horrible Assets UI to at least reach the standards of FGC's.


The operating system now does it when an application doesn't respond to message prompting from the OS.
Have the application respond to the OS then. If it cannot be done via its own watchguard thread then implement some other form of keepalive timeout. If this is not possible in Unity then d*mn, too bad.


I had segued into a possible solution and was musing over the difficulties and complexities associated with that solution...
The question is if FGU's deverlopers plan on doing something about it or if this is not even considered a (real) problem?! I get the impression of the latter, because the former is not openly communicated. I was just accused of intentionally wasting the developers time by reporting a possible memory leak. Where can it go from there?


Developers truly don't forget. People assume developers are nefarious and have all these plots about how to make peoples' lives miserable.
Absolutely not. But they tend to concentrate on the engine, deeming the UI something to put on top of the functionality, or expecting end-users to follow their paradigm. There often is a disconnect and support usually is the place that tries to re-establish that connection after the fact that the design is already set in (mind)stone. I do work with developers of drivers, software and hardware and I do work with end-users. I do understand the financial and time constraints that software is developed under. Transparent communication goes a long way to ease the pains.

[Jiminimonka]

Concise bug reports are cool.

Expecting the devs to explain their rationale is not cool.

[Weissrolf]

What does that tell us about the multi-threading discussion?

[Weissrolf]

- double post -