<i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint

[Jeremy]

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

So I'm generally hearing 3 responses to this ticket (so far):

1. My interpretation: we have this one known problem (where Window.java is calling `fillRect(..)`), and if we just flip a switch and avoid that code then the flicker is gone.
2. Alan's interpretation (see [8209329](https://bugs.openjdk.org/browse/JDK-8209329) ): we can eliminate the flicker by better synchronizing when the Window's surface data is flushed. (So `Window.paint(..)` can do anything it wants to: if we control when the monitor refreshes there won't be a flicker.)
3. Sergey's interpretation: if we make sure the Graphics we pass to `dirtyComponent.paint(..)` is the offscreen buffer, then that should also resolve the flicker.

Does this sound like a fair assessment, and if so: how do we decide which response to pursue?

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

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