That's interesting news!
A test class or at least some log timer may be useful in comparing speed improvements? One "adhoc" test I will do is zoom out to ~10% and then on a brand new launch/map, drag the hero token with dark vision, "expose only on waypoints off" and zig zag move the token back and forth (with waypoint) a set distance (like 10,000 feet). This causes MT to caclulate vision for every cell along that path and can take several seconds and is usually somewhat consistent.
1. Sure, if we can improve the code by x% that is ALWAYS welcomed!
2. Sure, again, if you can tackle that and improve upon it, go for it! A rewrite is probably still a long way off. Note, look the AreaTree class. You don't have to change every Area class reference to gain improvements right off. Also, keep in mind, I need to change this anyway to convex polygons eventually to work with LIBDGX. So really, it doesn't HAVE to be Area's. It can be a collection of convex polygons. I have a earclipping routine in my gdx code. If fact, IF everything was converted from Area to convex Polygons now, it would save me time going forward and be compatible! (if you are interested in this front, let me know. The libgdx code is a little more game orientated and interesting to work with)
3. Yea, I get a lot of the warning in Eclipse as well (until you turn some of them off lol). There is a lot of legacy code here but luckily NOW we don't HAVE to support it, so Java 8 spec is fine. HOWEVER, I would refrain from cleaning that up at this time. It should be a separate effort (or done as part as moving to JavaFX). A lot of the Swing code will go away anyway and if you perform evergreening on the code now, we'll just end up with a lot of class/code changes which will make debugging the math changes more of an issue.
Regarding Nerps_Logo, ya, I try to keep what is unique to my build separate from the master so it's easier on the pull requests. Did you Fork from my build? What branch? (One option is to Fork from 1.4.1-Dev from Rptools instead. Your work can be submitted to the master branch for consideration then as well (and I can merge it upstream). However, if you want to work on the libgdx and my fork, that is cool with me as well)
Do note, please run the Spotless gradle tasks before submitting any PR's. Since you are using IntelliJ, I'm sure your "Formatting" is not going to be exactly the same as what we have defined for Eclipse and comparing merges suck when every line is flagged because of tabs vs spaces and such.