Mapping too quickly creates inaccurate mapping stats

[PiTheGuy]

If you map something out, triggering a stat update, and then map something else before the update completes, the mapping stats for that class can become inaccurate. This may cause the stat icon to flicker and not always settle on the correct icon once it stops.

[PiTheGuy]

It appears ClassSelector.reload runs multiple times per stat reload. Every call has the same stacktrace, showing it has been called from the done method in the SwingWorker within ClassSelectorClassNode.reloadStats. The cause of this behaviour is unknown, but seems to be related to this bug report.

[supersaiyansubtlety]

It's called several times in moveClassTree:

• for obf+deobf selectors (instant)
• for allClassesSelector (instant)
• indirectly for the moved entry via reloadStats (non-instant)

[supersaiyansubtlety]

The multiple calls to ClassSelector's reloadStats(ClassEntry classEntry) are from Gui's reloadStats(ClassEntry classEntry, boolean propagate), one for each ClassesDocker.

[supersaiyansubtlety]

@PiTheGuy can you test the issue on this branch? https://github.com/supersaiyansubtlety/enigma/tree/discard-prior-stat-reloads

[PiTheGuy]

It does not appear to be fixed. Go to a large class and map out two things in quick succession. You should see the number change sporadically when you hover over the stat icon.

It's also worth noting that #207 appears to have resurfaced in that branch.

video.mp4

[supersaiyansubtlety]

I've started testing on LivingEntity and can reproduce the issue.
There were at least two reasons my solution wasn't working. One was an easy fix; I have an idea for the other I'll try asap.

[supersaiyansubtlety]

ok, this seems to work, please confirm: https://github.com/supersaiyansubtlety/enigma/tree/sequential-reloadStats

it takes a while, but in testing it always ended up at the right number

it makes it so Gui:reloadStats doesn't start its work until prior calls' work is complete, so the number will still "fluctuate" if you map and unmap quickly (the fluctuation reflects the correct number after each change you made, in order)

it makes no attempt to cancel prior work, which would speed things up, but I couldn't get that working (I may come back to it)

[supersaiyansubtlety]

Here's a version with cancelling: https://github.com/supersaiyansubtlety/enigma/tree/sequential-reloadStats%2Bcancelable

It's significantly faster if it cancels before stat generation starts.

Edit: I tried making StatsGenerator::generate methods cancelable but it had no effect; if generate was called, it always finished before being canceled.