Thanks for writing Alan. Yes, IMO our tickets share the same root cause.
To be clear: are you seeing the PR comments I’m leaving? I just
mentioned you a couple of times.
To your q:
> It is not clear to me how the proposed solution fixes a
synchronization problem.
My proposed solution does not fix the underlying synchronization
problem. My proposal (I think) circumvents the one spot of problem code
that we both independently concluded was causing a flicker. (So IMO my
proposal addresses the symptom; yours addresses the disease.)
I like the idea of a more thorough solution (like a universal fix to
make it *always* safely synchronized), but I’m also an inexperienced
contribute so I initially responded to this with a less invasive
approach. I’m happy to scale up the complexity if reviewers agree that
is a better path forward.
- Jeremy
------ Original Message ------
From "Alan Snyder" <[email protected]>
To "Jeremy" <[email protected]>
Cc [email protected]
Date 3/13/2023 10:39:29 PM
Subject Re: RFR: JDK-8303950: [macos]Translucent Windows Flicker on
Repaint
Please review my analysis of a problem that might be the same problem.
If it is not the same problem, it would be nice to fix that problem as
well given that the code is being changed.
[JDK-8209329] [macos] non-opaque Swing window flickers - Java Bug
System <https://bugs.openjdk.org/browse/JDK-8209329>
bugs.openjdk.org <https://bugs.openjdk.org/browse/JDK-8209329>
jira-favicon-hires.png
<https://bugs.openjdk.org/browse/JDK-8209329>
The problem I identified was caused by a lack of synchronization.
It is not clear to me how the proposed solution fixes a synchronization
problem.
Please explain.
Alan
On Mar 13, 2023, at 5:10 PM, Jeremy <[email protected]> wrote:
On Mon, 13 Mar 2023 22:27:51 GMT, Sergey Bylokhov <[email protected]>
wrote:
It is probably better to integrate this "clear" operation into the
peer and/or repaintmanager, and exclude it in this method.
Are you sure? (Or alternatively: maybe I don't understand what you
mean?)
By "clear operation" I assume you're referring to the call in
Window.java `gg2dfillRect`. This clear logic has existed since 2009,
so I'm reluctant to remove it. (And if we remove it: we can just
remove the entire `paint(Graphics)` method, because that's the only
reason it's overridden, right?)
Here's a screenshot of the code in question & a little git annotation:
<img width="1316" alt="image"
src="https://user-images.githubusercontent.com/7669569/224851605-e697e698-c4ee-439e-9e04-6b41659a12f4.png";>
If you still want me to try to migrate this logic: can you give me an
example of which classes you'd recommend trying to move it to?
-------------
PR: https://git.openjdk.org/jdk/pull/12993
![https://user-images.githubusercontent.com/7669569/224851605-e697e698-c4ee-439e-9e04-6b41659a12f4.png"](https://user-images.githubusercontent.com/7669569/224851605-e697e698-c4ee-439e-9e04-6b41659a12f4.png"){kind=link}