RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint [v2]

[Jeremy]

> # Problem Summary
> 
> For non-opaque windows, Window#paint calls `gg.fillRect(0, 0, getWidth(), getHeight())` before `super.paint(g)`.
> 
> This can cause flickering on Mac, and the flickering seems to have gotten much worse in recent JVMs. (See movie attachments to original ticket.)
> 
> # Discussion
> 
> This is my 2nd PR for this ticket. The original is [here](https://github.com/openjdk/jdk/pull/12993); that proposed change was IMO more invasive/scarier. It was auto-closed after 8 weeks of inactivity, and I'd rather offer this PR instead.
> 
> In that previous discussion Alan Snyder framed the core problem as a "lack of synchronization" (see [comment here](https://github.com/openjdk/jdk/pull/12993#issuecomment-1467528061)). If the monitor refreshes/flushes after we've called `fillRect` *but before we finish `super.paint`*: it makes sense that we'd see a flicker.
> 
> I agree with Alan, but I think the problem can also be framed as a mixing-Swing-with-AWT issue. (Which IMO will involve an easier fix.)
> 
> This PR is a low-risk change (relative to the previous PR) that intercepts calls to repaint a Window that is also RootPaneContainer. Now we'll redirect those calls to paint the JRootPane instead. This means we'll exclusively paint within Swing's/RepaintManager's double-buffered architecture, so we bypass the risky call to `fillRect` on the screen's Graphics2D. (And this change occurs within RepaintManager, so we're clearly already in Swing's architecture.)
> 
> So with this change: we paint everything to the double-buffer, and the *only time* we paint to the Window's Graphics2D is when have set up a AlphaComposite.Src and replace its contents with our buffer's contents.
> 
> # Tests
> 
> This PR includes a new test for 8303950 itself. This is pretty self-explanatory: we repaint a trivial animation for a few seconds and use the Robot to see if a pixel is the expected color.
> 
> This PR also includes a test called `bug8303950_legacyWindowPaintBehavior` that creates a grid of 4 windows with varying opacity/backgrounds:
> 
> <img width="805" alt="image" src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6">
> 
> I was surprised by how these windows rendered, but I don't think that's worth debating here. This test simply makes sure that we preserve this preexisting behavior. The broad "rules" appear to be:
> 1. If a JComponent identifies as opaque (see `JComponent.isOpaque`) then the JComponent's background is used. (In this case: that's the opaque green top two windows.) T...

Jeremy has updated the pull request incrementally with two additional commits since the last revision:

 - 8303950: Adding "@key headful"
   
   Based on prrace's feedback https://github.com/openjdk/jdk/pull/14363#issuecomment-1581365662
 - 8303950: remove call to Window#toBack()
   
   toBack() moves the Window behind *everything*. If it moved windows only behind other windows in the Swing app that would be great, but that's not what it does.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14363/files
  - new: https://git.openjdk.org/jdk/pull/14363/files/37834391..2c093210

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=00-01

  Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14363/head:pull/14363

PR: https://git.openjdk.org/jdk/pull/14363