I think that any speed gain will not be measurable.
I think that any speed gain will not be measurable.
I think that it would be ...
... however I do not know how the engine works internally, nor the technologies being used. I can only make statements based on my personal development experience.
Anyways ... this was not an attempt to analyse FGU, but rather a comment that developed from the concept of creating windows "on the fly" from myself.
Look at the FG console.log file - it has timings after various startup events - for example:
This is for PFRPG2:
The numbers are seconds - so CoreRPG + PFRPG2 take 8.1 seconds in this instance.Code:[2/21/2023 10:11:30 AM] MEASURE: RULESETS LOAD - 8.1196016 - PFRPG2
[2/21/2023 10:11:30 AM] MEASURE: EXTENSIONS LOAD - 0.0009998 - 0
[2/21/2023 10:11:44 AM] MEASURE: MODULE LIST BUILD - 13.3296355 - 578
[2/21/2023 10:11:44 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1744114
[2/21/2023 10:11:44 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0261647
[2/21/2023 10:11:44 AM] MEASURE: REFRESH TOKEN ASSETS - 0.1334217
[2/21/2023 10:11:44 AM] MEASURE: ASSET LIST BUILD - 0.3339978
[2/21/2023 10:11:47 AM] MEASURE: LOAD - PART 1 - 25.312245
For a CoreRPG only campaign, it takes about 7 seconds:
But most of that is file operations unpacking the CoreRPG.pak file. If I run CoreRPG from a folder (as an example, don't do this normally) it's 0.7 second:Code:[2/21/2023 10:27:31 AM] MEASURE: RULESETS LOAD - 6.9057168 - CoreRPG
[2/21/2023 10:27:31 AM] MEASURE: EXTENSIONS LOAD - 0.0039304 - 1
[2/21/2023 10:27:35 AM] MEASURE: MODULE LIST BUILD - 4.1013325 - 366
[2/21/2023 10:27:35 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1042792
[2/21/2023 10:27:35 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0157715
[2/21/2023 10:27:35 AM] MEASURE: REFRESH TOKEN ASSETS - 0.1014426
[2/21/2023 10:27:35 AM] MEASURE: ASSET LIST BUILD - 0.2214933
[2/21/2023 10:27:36 AM] MEASURE: LOAD - PART 1 - 11.8744561
So, hiding stuff in CoreRPG rather than removing it is probably only going to have an impact of less than a second on load time.Code:[2/21/2023 10:29:43 AM] MEASURE: RULESETS LOAD - 0.6363449 - CoreRPG
[2/21/2023 10:29:43 AM] MEASURE: EXTENSIONS LOAD - 0.0019943 - 1
[2/21/2023 10:29:48 AM] MEASURE: MODULE LIST BUILD - 4.9318076 - 366
[2/21/2023 10:29:48 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1379166
[2/21/2023 10:29:48 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0302827
[2/21/2023 10:29:48 AM] MEASURE: REFRESH TOKEN ASSETS - 0.10226
[2/21/2023 10:29:48 AM] MEASURE: ASSET LIST BUILD - 0.2729979
[2/21/2023 10:29:48 AM] MEASURE: LOAD - PART 1 - 6.0839003
[2/21/2023 10:29:49 AM] [WARNING] [RULESET: CoreRPG][Prioritized Source: Folder; Other Sources: File]
[2/21/2023 10:29:49 AM] MEASURE: LOAD - PART 2 - 0.7859316
You can do this - either replacing subwindow content (as I mentioned in post #13) or you can use code to create a skeleton window and then populate with controls using the window.createControl API: https://fantasygroundsunity.atlassia...#createControlQuote:
Originally Posted by UrsaTeddy
@Trenloe ... I believe that the original poster wanted to add/subtract controls on a previously built window. Therefore the "empty window" then "create on the fly" option would be more complicated for them.
As to the timings issue - it may just be that using a Mac or the Ruleset that I use that makes the application feel a little "clunky". I have a powerful machine as well as a lot of memory - I do not run a windows machine here to test my theory at this point.
Anyways as I previously said, it was just something I noted - not an attempt to disparage the software itself. Sometimes cross platforming just doesn't work the same on other OSes.
I was more referring to your comments regarding creating windows on the fly. The OP was asking about one individual control - which is pretty easy to do, with solutions already presented in this thread. Maybe it's just terminology, but your comment of "It would be so much easier if you could load a WindowClass dynamically during runtime." took the original discussion in a different direction, specifically referring to windows not individual controls - and that's what I've been replying to since.Quote:
Originally Posted by UrsaTeddy
@Trenloe ... perhaps my terminology was not correctly placed. The statement I made was that you could not create a Window on the fly because you had to have a WindowClass template in an XML file in the first place.
However with an empty WindowClass template - as you stated - you could then create your window contents and sub windows without issue.
Once again I was not attempting to disparage FGU (or yourself) - I have been using it for quite some time and do not see myself not using it - I was just pointing out to the Original Poster that he would have to create two WindowClasses (one for each user type) and have them loaded at runtime as per the normal system.
You cannot load a WindowClass dynamically or "on demand" (instead of having all Window Classes load at runtime) ... that is what I was meaning to state ... or am I incorrect in that statement?
I didn't think you were disparaging FG at all. I'm purely responding to questions/statements offering options that may not have been known.Quote:
Originally Posted by UrsaTeddy
You're correct that you can't "create" a windowclass on the fly, you can "load" a windowclass on the fly. To do something similar to creating a windowclass on the fly (and the controls in it), you'll need a windowclass defined in XML somewhere - hence my suggestion of building controls within a windowclass template as needed, which may not be appropriate for complex windows. Maybe it might help, if you're wanting feedback/suggestions, to take this to a new thread to discuss further? As maybe there are solutions to your specific requirements.
@Trenloe ... all is good from my end ... my thoughts were confirmed by yourself ... the original poster received a couple of ideas on how they may proceed ... and I need to get my hands on a windows machine to check the speed/clunkiness of FGU that I seem to notice on a Mac.
Thank you for your willingness to discuss and help.