wolph42 wrote:@Az, does it happen with a clean campaign file already or does it happen with certain .cmpgn files? If its the latter, then maybe you can share one so we can test as well.
Okay, so it only happens on very busy maps. Which is understandable. By "very busy" I mean maps with
lots of VBL and
a few dozen tokens.
If its the former, than I can't reproduce as well, tried both a clean map and my rather heavy framework, both were snappy also in creating a new map.
It does seem to be rather snappy on my "typical" maps. And I just used a new feature of b85 to reset all fog when importing a new map and it seems to be running much faster. I then went through and cleared away fog throughout the castle for 4-5 PC tokens and the performance stayed fine. So I believe the lag to be a combination of complicated VBL and "left over" fog from a previous version.
Maybe its wise to share the campaign file anyway you tested this on.
The map itself is too large to attach here, but I've uploaded it to my web site. You can find it at
http://www.eeconsulting.net/maptool/test/ -- the name is
Castle Korvosa.rpmap. This is the original export that still has all of the fog in it (exported in b84). You can try loading it both with and without clearing the fog.
Running the profiler on it did indicate a "hot spot" but the execution time of that code was only about 10% of the total (real) run time of the application and I was heavily testing mouseover and token selection (since those seemed to be the slowest).
My best guess is that the exposed area was so complicated that the calculations that merge exposed fog areas was taking a noticeable amount of time. That can be helped using a cache, but I'll let others take a look at my export map before we discuss that further.