SilentRuin
October 31st, 2022, 18:19
It seems that FGU devs could gain a lot of performance improvement in large crowded maps or complex LOS if they simply implement the onMeasurePointer function triggers with a bit more care. Right now this seems to be triggered a ton of times which seems a bit of an overkill. Perhaps only trigger if it the last mouse movement was more than a trivial amount of space. If your in a basic map with few tokens and an LOS of simplistic design you won't notice the difference. But this is not something that should be the test case to locate performance issues. Only complex LOS with crowded maps will expose the true performance issues and I'd like FGU devs to pretty much have some standard test case like that they run through all their code on to locate these performance slow downs.
But for now - I'm only really noticing the onMeasurePointer performance which in a legit complex performance test will become obvious simply by having 5-6 targets and moving the token that is doing the targeting - you will see a marked slowdown - turning off the targets (thus no onMeasurePointer graphics redraw of distance/lines) will show a marked performance increase. Simplifying the onMeasurePointer triggers to not trigger at every minute mouse move would go a long way to improving this performance. As long as it insures its triggered when the token drag stops - it can't NOT be correct. And only doing some of the mouse moves between drag start and drag end would be a large improvement on performance.
I'd rather not do a modification to my extensions to handle this.
But for now - I'm only really noticing the onMeasurePointer performance which in a legit complex performance test will become obvious simply by having 5-6 targets and moving the token that is doing the targeting - you will see a marked slowdown - turning off the targets (thus no onMeasurePointer graphics redraw of distance/lines) will show a marked performance increase. Simplifying the onMeasurePointer triggers to not trigger at every minute mouse move would go a long way to improving this performance. As long as it insures its triggered when the token drag stops - it can't NOT be correct. And only doing some of the mouse moves between drag start and drag end would be a large improvement on performance.
I'd rather not do a modification to my extensions to handle this.