Ah, I see. I'll try to add that in, though I have a feeling that most of the time involved is the actual string operations themselves. But, I did what I could to front load the heavy lifting, so my setup now takes about half a second to initialize, but a bit less to resize than it did before (which was still quick enough to allow for smooth resizing). But, I don't really have a super complicated GUI (around 150 objects displayed) so I don't know at what point it will start slowing down.
I think I can probably shave a bit in computing the measurements since everything gets run through the simplify algorithm, meaning I know what the values look like all the time ("###%", "###%" + ###px", or "###px").
Simple Window Handling
Re: Simple Window Handling
I updated the original post with a few improvements. First, I modified the math function to allow you to multiply and divide by percents ("25%" for example). Second, I significantly sped up the calcScaledNum function (since it now should only be seeing simplified results (but I made sure to put in a check to ensure it had simplified results). So, now I am seeing start up times of a bit less than 0.1 seconds, and window resize times of 0.003 seconds (both measured using the stopWatch provided in Mudlet, just starting it, raising the sysConnectionEvent or sysWindowResizeEvent, then stopping it and displaying the time elapsed).
Init times, but not resize times, do seem to increase with multiple iterations though, and I'm not sure why. Any ideas as to why? (And, I know, I have a lot of other things going on in addition to the GUI stuff when I connect, so it could possibly be there.)
Init times, but not resize times, do seem to increase with multiple iterations though, and I'm not sure why. Any ideas as to why? (And, I know, I have a lot of other things going on in addition to the GUI stuff when I connect, so it could possibly be there.)
Re: Simple Window Handling
I'm not certain, but since all scripts are loaded and run at init - you could add a script that prints the stopwatch time before all of your scripts, sprinkle a few in the middle, and have one at the end. If that accounts for most of the delta increase you have in init vs resize, then it would be your scripts taking the time (and you could pin down which, too).
Re: Simple Window Handling
So, checking on run times, I see that the biggest contributor (and particularly the one that grows the fastest) is my attempt to kill all temp triggers so that I don't get duplicates created by my scripts. What is worse, is that I know it is wasting a lot of effort, since it seems like the trigger indexes don't get recycled (and it kills every trigger from index 1 to a new one it makes to get the highest index).
Is there a better way to kill all temp triggers? (as a comparison, the trigger killing section is growing by about .02 to 0.03 sections per iteration, my GUI setup is growing by about .005 per iteration.) It isn't really huge either way, but it seems like there should be a better way to handle something like this. I guess maybe I could log every temp trigger in a central table, and remove them when I kill them... though, that still allows some problems to crop up in the event someone does something dumb and clears the table.
Is there a better way to kill all temp triggers? (as a comparison, the trigger killing section is growing by about .02 to 0.03 sections per iteration, my GUI setup is growing by about .005 per iteration.) It isn't really huge either way, but it seems like there should be a better way to handle something like this. I guess maybe I could log every temp trigger in a central table, and remove them when I kill them... though, that still allows some problems to crop up in the event someone does something dumb and clears the table.
Re: Simple Window Handling
There isn't a better way to kill them, but having a "loaded" flag so you don't load them again would work.
Re: Simple Window Handling
Well, tracking them in a table and killing just those certainly saved a lot in load times, though that still grows, which is odd since it should be killing a fixed number of triggers each time.
Re: Simple Window Handling
I can share this observation. I've made a test case that demonstrates this and reported it here.
Re: Simple Window Handling
Thanks. At least that explains what is going on. Always good to know that a problem isn't just happening to me.