There is a problem with the display on macos

[Richard-Tang]

The same jar package code, when displayed on MACOS, there will be a visual bug.

When I drag and drop on MACOS, it looks like this: the feature works, but it doesn't appear as complete as it does on Windows.

java 11.0.16.1 2022-08-18 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.16.1+1-LTS-1)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.16.1+1-LTS-1, mixed mode)

It is displayed normally on windows

java 11.0.12 2021-07-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.12+8-LTS-237)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.12+8-LTS-237, mixed mode)

[andrewauclair]

Unfortunately, I don't own a Mac and don't have access to one. I did recently rework how the sizes are chosen for the overlay and floating frame. Maybe that will fix the issue. I'm going to be publishing a 0.6.0 soon (possibly today).

[Richard-Tang]

Unfortunately, I don't own a Mac and don't have access to one. I did recently rework how the sizes are chosen for the overlay and floating frame. Maybe that will fix the issue. I'm going to be publishing a 0.6.0 soon (possibly today).

The new 0.0.6 code will still have this problem

[tlf30]

You may try jdk 19. I have seen a lot of issues in jdk 11 & 17 with swing for some reason, but jdk 19 seems to fix all but one that I have come across

[tlf30]

I'm now seeing a similar on JDK 17 with 4k displays, also the drop locations are not correct. I think this may be a java issue. I will test with JDK 19 on the same displays and see how it behaves.

[andrewauclair]

I do recall there being some dpi issues with an older version. I will see if I can reproduce the issue with some older versions and display settings.

[tlf30]

So, on windows, with JDK 20, with two different screens, there are strange issues with rendering the drop points.
Tested Screens
3840x2160
5120x1440

The drop overlay renders in a strange blue color, and does not even necessary overlap with the entire app. Instead it is in the upper left of the app. The actual look of the overlay looks nothing like what it should, and instead is just a rectangle or two that is light blue. But on my super wide monitor, it correctly renders the overlap with the correct blue shading, but it does not size correctly.

[andrewauclair]

Wow, that is very strange. I'll see if I can get it to do that. So far, I have tried it out on Java 9 with 150% scaling and I see an issue there with the position when floating a dockable. The overlay has looked ok though.

[andrewauclair]

So, on windows, with JDK 20, with two different screens, there are strange issues with rendering the drop points. Tested Screens 3840x2160 5120x1440

The drop overlay renders in a strange blue color, and does not even necessary overlap with the entire app. Instead it is in the upper left of the app. The actual look of the overlay looks nothing like what it should, and instead is just a rectangle or two that is light blue. But on my super wide monitor, it correctly renders the overlap with the correct blue shading, but it does not size correctly.

I wonder if it is confused about which window your mouse is over. At least in that first image, the highlight looks to be the perfect size to fit in the top half of the other frame.

[andrewauclair]

Wow, no. That's the dockable that's floating, not another frame. Forget what I said (It has been too long of a day).

[andrewauclair]

for (GraphicsDevice screenDevice : env.getScreenDevices()) {
    System.out.println("scale for: " + screenDevice.getIDstring() + ": " + screenDevice.getDefaultConfiguration().getDefaultTransform().getScaleX() + ", " + screenDevice.getDefaultConfiguration().getDefaultTransform().getScaleY());
}

@tlf30 Hey, could you tell me what this code outputs on your setup?

I believe most of this boils down to me not using the scaling properly. Essentially that makes almost all the positioning wrong. Funny enough, the center docking handles are the only things I use the scale for. That's why they appear huge in the original screenshot in this issue.

I did more testing on 150% and the drag position was way off. I scaled the mouse position using the above code and the position was fixed. However, that only works on the 150% monitor. I need to figure out how you tell which monitor you're on and using the scaling for that. This might take some time.

[tlf30]

Absolutely, here is the output

scale for: \Display0: 1.25, 1.25
scale for: \Display1: 2.0, 2.0

[Richard-Tang]

I'm now seeing a similar on JDK 17 with 4k displays, also the drop locations are not correct. I think this may be a java issue. I will test with JDK 19 on the same displays and see how it behaves.

I tested it on macos jdk19 and found the same problem.

When I try to drag, the component behind the background temporarily disappears.

[andrewauclair]

Hard to see, but it looks like the DockingUtilsFrame where the handles are drawn isn't being hidden. This frame is set as undecorated (this part looks to be working) and the background is set to new Color(0, 0, 0, 0) to make it transparent. This must not work properly on macOS. I'll see if the internet has any suggestions.

[andrewauclair]

@Richard-Tang It turns out that transparency works a little different on macOS. I have committed a change to use the client property "Window.alpha". Apparently you have to set that to 0.0f instead of using setBackground(new Color(0, 0, 0, 0));

If you're able to try it out, that would be great. I am still investigating the other scaling issues.

[Richard-Tang]

@Richard-Tang It turns out that transparency works a little different on macOS. I have committed a change to use the client property "Window.alpha". Apparently you have to set that to 0.0f instead of using setBackground(new Color(0, 0, 0, 0));

If you're able to try it out, that would be great. I am still investigating the other scaling issues.

This time it is indeed transparent, but without ModernDocking layout display!

The original layout component is no longer displayed.

[andrewauclair]

@Richard-Tang Interesting. We're learning something! I've been doing some research about translucency/transparency in Java Swing. I've added a new test class to basic-demo. Could you run TranslucentTest.java and comment here with what the output is.

For example, when I run it on my Windows 11 machine it outputs the following.

Is uniform translucency supported: true
Is per-pixel translucency supported: true
Is shaped window supported: true

[andrewauclair]

I suspect that macOS doesn't support the per-pixel translucency and that's what we're seeing here. Either way, this looks like something I need to consider and have a backup solution for when the transparency tricks won't work.

[Richard-Tang]

For example, when I run it on my Windows 11 machine it outputs the following.

> Task :TranslucentTest.main()
Is uniform translucency supported: true
Is per-pixel translucency supported: true
Is shaped window supported: true

[andrewauclair]

Well, there goes that theory. I guess macOS supports it but it doesn't work the same.

[andrewauclair]

@Richard-Tang Undid the previous change and set the background color of the content pane to be transparent. I have my fingers crossed that does something, if you wouldn't mind trying.

[andrewauclair]

I made another change based on what was discovered in Issue #68 that might be related to this issue as well. I am publishing a 0.6.1 right now which should be available on maven central later this morning.

[Richard-Tang]

#68 This solves the translucent issue on MacOS

But in the latest code, instanceof JComponen，Actually getContentPane() is a JPanel

try {
	if (getContentPane() instanceof JComponent) {
		((JComponent) getContentPane()).setOpaque(false);
	}
}
catch (IllegalComponentStateException e) {
	// TODO we need to handle platforms that don't support translucent display
	// this exception indicates that the platform doesn't support changing the opacity
}

It currently works on MacOS ((JComponent) getContentPane()).setOpaque(false);

[andrewauclair]

A JPanel is a JComponent. getContentPane() returns a Container so I didn't want to make too many assumptions.

Looks good. Something still seems a little off with the handles, but at least they're rendering with transparency.

[andrewauclair]

@Richard-Tang Could you try out the latest? I wrote issue #72 related to this issue. Turns out, the special RepaintManager that I use to check for EDT violations breaks the transparency on Linux and I suspect the same happens on MacOS. I modified the demo to have this off by default.

This would also be a problem for apps derived from my example code if they kept the FailOnThreadViolationRepaintManager.install(); line.

[Richard-Tang]

--laf=light

--laf=light --enable-edt-violation-detector=true

--laf=dark --enable-edt-violation-detector=true

Now the test situation is that the add --enable-edt-violation-detector, Will have display problems.

[andrewauclair]

I'm a little confused. Is there a missing screenshot there with the detector off?

[Richard-Tang]

--laf=dark --enable-edt-violation-detector=false

--laf=light --enable-edt-violation-detector=false

[andrewauclair]

Damn :( I really thought that was going to be it.

[andrewauclair]

Interesting that it has regressed. I am seeing some look and feel issue with the demo where the backgrounds always stay white. Not sure if it's related, but I do have a fix for it.

[andrewauclair]

@Richard-Tang Getting back to this again. What does it display with --laf=system --enable-edt-violation-detector=false?

I noticed that before when it was working you were running my Example.java and now when it wasn't working again you were using the basic demo MainFrame.java. I wonder if it's some issue with those look and feels on MacOS.

Edit: Sorry, that was supposed to say --laf=system. Copy paste mistake.

[andrewauclair]

I came across this FlatLaf MacOS transparency issue last night (JFormDesigner/FlatLaf#705) that has a very similar issue. I will try the suggested workaround for 0.7.2.

[andrewauclair]

0.7.2 has the workaround in it now.

[andrewauclair]

Closing. I believe this has been resolved.