<html><head>
<style id="css_styles">
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
table { border-collapse: collapse; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] { list-style-position: inside;}
body { font-family: Helvetica; font-size: 9pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }
a.em-mention[href] { text-decoration: none; color: inherit; border-radius: 3px; padding-left: 2px; padding-right: 2px; background-color: #e2e2e2; }
</style>
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Bug <a href="https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8344697" class="__cef_visited">8344697</a> points out that the Aqua L&F (in Swing) has logic to constantly repaint the JRootPane’s default button.<div><br /></div><div>I’m pretty sure that feature is now obsolete. Back with Mac OS Mavericks (Mac OS 10.9) the default button continually pulsed (see <a href="https://drive.google.com/file/d/1-ns_iYbnJOKJi0e3okaOBBrWTF07DLVk/view?usp=drive_fs">example</a>), but Apple stopped supporting Mavericks around 2016. All subsequent OS’s do not repaint that button.</div><div><br /></div><div>However:</div><div>The resolution to <span><a href="https://bugs.openjdk.org/browse/JDK-8342782" class="__cef_visited">JDK-8342782</a> changes things. The repaint logic is still obsolete, but it no longer results in a demonstrable performance problem.</span></div><div><span><br /></span></div><div><span>My questions are:</span></div><div><span><br /></span></div><div><span>1. Is </span>obsolescence enough of a reason to submit a PR to remove this feature? (Can I submit a PR like this without a test case?)</div><div><span>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.)</span></div><div><br /></div><div>Additional context:</div><div><br /></div><div>I wrote a test to demonstrate how the code responsible for pulsing the button used to be very expensive (see <a href="https://github.com/mickleness/jdk/blob/JDK-8344697/test/jdk/com/apple/laf/RootPane/RootPaneScrollingPerformanceTest.java">test</a>). 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:</div><div><br /></div><div>> The time it took by default was: 35923</div><div>> The time it took when suppressing AncestorListeners was: 112</div><div><br /></div><div>However now having merged the recent changes for <a href="https://bugs.openjdk.org/browse/JDK-8342782" class="__cef_visited">8342782</a>, this performance gap appears satisfactorily fixed:</div><div><br /></div><div>> The time it took by default was: 287</div><div>> The time it took when suppressing AncestorListeners was: 215</div></body></html>