> # 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 one additional commit since the last revision: 8303950: removing unnecessary whitespace in unit test See https://github.com/openjdk/jdk/pull/14363#pullrequestreview-1484315506 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14363/files - new: https://git.openjdk.org/jdk/pull/14363/files/2c093210..12d8950d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14363&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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
