Bug 8344697
<https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8344697> points
out that the Aqua L&F (in Swing) has logic to constantly repaint the
JRootPane’s default button.
I’m pretty sure that feature is now obsolete. Back with Mac OS Mavericks
(Mac OS 10.9) the default button continually pulsed (see example
<https://drive.google.com/file/d/1-ns_iYbnJOKJi0e3okaOBBrWTF07DLVk/view?usp=drive_fs>),
but Apple stopped supporting Mavericks around 2016. All subsequent OS’s
do not repaint that button.
However:
The resolution to JDK-8342782
<https://bugs.openjdk.org/browse/JDK-8342782> changes things. The
repaint logic is still obsolete, but it no longer results in a
demonstrable performance problem.
My questions are:
1. Is obsolescence enough of a reason to submit a PR to remove this
feature? (Can I submit a PR like this without a test case?)
2. And/or can anyone help me brainstorm a realistic/compelling test case
that demonstrates this feature is still problematic? (It adds a
AncestorListener to *every* AbstractButton.)
Additional context:
I wrote a test to demonstrate how the code responsible for pulsing the
button used to be very expensive (see test
<https://github.com/mickleness/jdk/blob/JDK-8344697/test/jdk/com/apple/laf/RootPane/RootPaneScrollingPerformanceTest.java>).
It scrolls a large panel with 5000 JCheckBoxes, and performance varies
wildly based on whether Aqua’s default button logic is used. When I
first wrote it the output included:
> The time it took by default was: 35923
> The time it took when suppressing AncestorListeners was: 112
However now having merged the recent changes for 8342782
<https://bugs.openjdk.org/browse/JDK-8342782>, this performance gap
appears satisfactorily fixed:
> The time it took by default was: 287
> The time it took when suppressing AncestorListeners was: 215
