My input:
Doesn't display properly on HiDPI displays - allow for 150% / 200% scaling.
The submit 'take a screenshot' takes a long time when running high resolution displays. If you're going to implement a result submission that relies on a checksum, I'd suggested limiting the screenshot to an ALT+PRTSCN application that just captures the benchmark window.
Show the time taken to process the benchmark at the end
Show the estimated time to complete during the benchmark
Allow a command line interface to run the benchmark which screenshots the result, saves the HWBOT file, and quits out automatically. That way someone could script up 50 runs and just choose to submit the best.
Automatically generate a result text file with a verbose output, or in the log include the benchmark result.
Include 8K. For LOLz.
Out of interest, have you spoken at all to MultiCoreWare in preparing this benchmark? They develop the x265 algorithm which is meant to be the toughest and most efficient in the business. I had a good long chat with their VP of product management about our own x265 encoding tests at AnandTech, relating to overclocked stability while transcoding, last week at IDF. We even discussed the potential of an open benchmark, like x264 HD 5.0 and the like. Looks like you're already ahead here, albeit with Java in tow. But it might be interesting if you did a cross collaboration on this. I can make intros where necessary, hit me up.