Fix high CPU load in grid customizer (GH9060)

[neilcsmith-net]

Ensure the animation layer paint is called at least once inside paintComponent so that the animation timer is shut down.

This is a minimal fix for #9060. If a change is made that triggers no change in bounds, then animation was set to false. However, if an existing animation was active at that time, the animation layer timer isn't stopped because animLayer.paint(..) isn't called during repaint. This causes a doom loop of repaint requests with excessive CPU usage.

This whole animation layer code is a little suspect - ideally it would exit cleanly during the timer listener - but it doesn't seem worth doing a full refactor for a little used feature.

Fixes #9060

[mbien]

should work I think. I was a little worried about all those if (phase == 1f) checks but it should be 1f still.

[neilcsmith-net]

Yes, there is much that is questionable in that animation layer, but I didn't want to do a lot of refactoring. The phase seems to always be set by a constant. Considered changing to if (phase >= 1f) at https://github.com/neilcsmith-net/netbeans/blob/master/java/form/src/org/netbeans/modules/form/layoutsupport/griddesigner/AnimationLayer.java#L288 Can still do that, or merge as is?

[mbien]

i think its fine to be merged as is since the rendering code in updatePhase() has phase = Math.min(Math.max(0,phase), 1f); as last statement.

The only place which resets the phase to 0 is the if block above your change.

[neilcsmith-net]

Thanks, same analysis as me. OK, merging.