antialias-when-still interferes with ui and interaction on large puzzles

[donhatch]

I find large puzzles (e.g. hypermegaminx) to be not very usable
when antialias-when-still (the "Allow Antialiasing" checkbox) is enabled:
the antialiased view takes 2 seconds to render, and it's on the swing event/interaction thread, which means lots of 2-second pauses during which both the ui and the view/controller mouse interaction are locked up.
It's not as bad as it was before Melinda's fix for issue #136, but it still seems like a significant usability obstacle to me. Melinda doesn't experience this as as significant a problem as I do.

It seems to me that these frequent 2-second lockups violate swing's ethic "Time-consuming tasks should not be run on the Event Dispatch Thread (EDT). Otherwise the application becomes unresponsive.".

Here's an idea for fixing that: never do the antialiased render directly to the view component in paint() or paintComponent() (both of which happen on the swing EDT). The high-quality antialiased picture is pure gravy in any case, right? So, when we want that expensive pretty picture (i.e. when the picture becomes "still"), then tell a worker thread to make the picture, into an offscreen Buffer object. If that worker thread completes the pretty picture before the user starts interacting again, then great, render it. Otherwise throw it away. So then neither the ui, nor any interaction in the view/controller window, nor newly initiated animations, will be delayed at all by these expensive renders.

[cutelyaware]

Swing is supposedly double buffered by default. It sounds like you want to implement triple buffering.

[donhatch]

It sounds like you want to implement triple buffering.

Yes, in a limited sense. Note that most frames would still be computed and rendered normally into swing's back buffer; i.e. normal double-buffering as usual.
It's only these gravy high-quality frames (which take something like 20 times as long to render as a normal frame, for megaminx) that would use an explicit third buffer, which would eventually be drawImage()'d into swing's back buffer (or discarded).

[cutelyaware]

Yep, that all sounds right. For me it's not a high priority since users are already in control of things needed to get decent frame rates from large puzzles they intend to invest heavily into solving. Like for sure they'd want to turn off shadows. But if you want to do it, we can discuss ways to graft it into MC4DView.

[donhatch]

Are you sure users are aware of what boxes they need to tick/untick in order to make a large puzzle usable? I wouldn't have guessed shadows matter (you've mentioned it to me before, but I forgot, and will again). And I imagine few people would guess that "Allow antialiasing" matters, or even what it means, even if they know what antialiasing is. (TBH "Allow antialiasing" is a cryptic phrase. Suggestion: call it what it is: "Antialias when still"; that's what I call it.)

No, I'm not interested in implementing what would be needed to make antialias-when-still usable for large puzzles. I'm basically just reporting the problem and how I think it could be fixed if anyone was interested in making it work. Personally, I think the best option would be to start by unchecking that box by default, since it doesn't feel like a production quality feature, and no one is planning to do anything that will make it into one.

I know you're not going to follow that advice, but I hope you'll at least try to make the fact that antialiasing + usability + large puzzles is a "choose two" situation discoverable, somehow. You might add tooltips, clearer checkbox labels, dire warnings if someone has a sufficiently large puzzle with antialiasing and/or shadows turned on, ... something.

If this doesn't seem important enough to you to do anything about, you could just close this issue as "Won't Fix".

[donhatch]

I apologize for the combative/insulting tone of my previous message.

Melinda and I are now discussing the issue in email.