Show estimated calculation time of optimizer

[Prezombie]

It's very easy for new users to bog down the tool with a combinatoric explosion. The tool clearly knows how many templates the current setting will generate, and a quick benchmark of a fixed number would give the tool a good idea of the calculation rate.

If the tool sees a large enough time, say 30 minutes, give a warning before starting, and maybe do a quick how to get the most of the optimizer in reasonable time frames.

[marcustyphoon]

Another excellent idea. I would probably not interrupt the user flow with a warning, since there's really no drawback of starting the long calculation in any case, but an estimated time display and an information display make a ton of sense.

[marcustyphoon]

Interesting: this is actually somewhat difficult to do precisely due to the way I modified the "don't test duplicate results" code. Only one of a pair of results like "berserker ring, assassin ring" and "assassin ring, berserker ring" will get calculated, but they both count in the internal percentage progress counter. This, as well as the unpredictability of result UI updates (which are incredibly slow with our current code, but get skipped if the result table doesn't change for a while) makes progress kind of jumpy, so a real-time time estimate swings pretty widely like a stereotypical Windows file copy progress bar window. Still good enough to detect long calculations, though.

[Prezombie]

I don't think a constantly updating timer is that important, or even one that's hyper accurate. Simply letting users know the order of magnitude of the current job would be useful enough.

You could also have the page's tab title change to reflect the current job, so it's clear the job is processing or done when you're in a different tab.

[marcustyphoon]

You could also have the page's tab title change to reflect the current job, so it's clear the job is processing or done when you're in a different tab.

Mostly unrelated, but worth a note that because the calculation code is currently done in the same cpu thread as page rendering, putting the optimizer in a background tab may trigger browsers' "reduce CPU spent on non-visible page animations" code and slow down calculation. Putting it as the foreground tab in a background window, on the other hand, seems to work fine.

(I'm kind of waiting for Firefox to get support for a certain feature to improve this.)