[Theming] Maximizing windows incorrect with Windows scaling and multiple screens

[ed-erwin-tf]

Radiance 6+, Theming, Java 11 (Corretto 11.0.15+9-LTS), Windows 10

Something changed between Radiance 5.0 and 6.0 that affects Frame maximizing on Windows for decorated frames.

Short description:

With Java 11, undecorated frames work very well for all LAFs including Radiance 5.0.0 and 6.0.1 and 6.5.0, Metal LAF, and Nimbus LAF. (There are very tiny differences in reported window sizes in different LAFs, but all look correct. None cover the taskbar.)

Radiance 5.0.0, or Metal LAF with decorated frames, maximize fills full screen ignoring (and thus covering up) taskbar. Maximizing on a secondary screen remains on that secondary screen.

Radiance 6.0.1, or 6.5.0 with decorated frames, maximize applies an incorrect scale factor. Maximize subtracts some space for taskbar, but starting from too-large dimensions. Maximize may go to wrong screen. (Seems to go to 0,0 even if that is on another screen.)

(Note there are older issue reports related to maximizing. Some of those may have been related to the JDK itself. Note also that Nimbus always uses undecorated frames.)

By decorated, I mean: JFrame.setDefaultLookAndFeelDecorated(true);

[ed-erwin-tf]

I will attach my detailed notes later today.

[kirill-grouchnikov]

To clarify - when you say "undecorated", you don't mean a JFrame with JFrame.setUndecorated(true) call on it. You mean a JFrame with its top-level decoration (title pane and window border) coming from the operating system, right?

And by decorated you mean a JFrame with its top-level decoration coming from Radiance?

[ed-erwin-tf]

I clarified it above: By decorated, I mean: JFrame.setDefaultLookAndFeelDecorated(true); By undecorated, I mean: JFrame.setDefaultLookAndFeelDecorated(false); I have not tried modifying that on an individual frame with "setUndecorated".

[kirill-grouchnikov]

https://github.com/kirill-grouchnikov/radiance/commit/97e9bb7f7432561e467d598811888f036857d7c4 went into version 6.0 to address that issue of maximizing Radiance-decorated windows that would ignore the taskbar.

https://github.com/kirill-grouchnikov/radiance/issues/379 has the details with the link to a 20-year old bug in Java (see https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4737788) and more relevant info at https://github.com/kirill-grouchnikov/aurora/issues/13#issuecomment-1017017814

That fix only applies for Java versions earlier than 15. This is probably the cause of the behavior change you're seeing here.

[ed-erwin-tf]

I've no doubt that the code in 379 is related. I can see that setting max bounds to (0,0, x,y) is likely responsible for sometimes moving the frame to a different screen. (Whichever screen has point 0,0 in it.)

That old java bug appears to have been fixed in my JRE 11, as confirmed by my testing, but maybe not all JRE 11?

I wonder if there might be a way for you to let developers swap-out the logic in the maximize button action. That would allow workarounds for people using different versions of java. (I attempted to do that by replacing the entire title pane UI, but didn't have time to finish, and it would be an ugly solution anyway.)

Maybe I'll try a JDK 9 and JDK 17 and see what happens.

[kirill-grouchnikov]

Are you seeing this only in Corretto 11, or also in the canonical Oracle 11 of JDK?

I don't do any testing on other JDK vendors. Just too many of them out there.

[kirill-grouchnikov]

Doing developer-provided overrides in the title pane buttons is interesting.

It's along the same lines as what we've talked about in https://github.com/kirill-grouchnikov/radiance/commit/0a0c2e415512304053abf07342143173601b60b4#commitcomment-93364364 - to allow developers to provide their own icon for the title pane buttons.

I'm still thinking about how to best address that one, and perhaps it can be something a bit more generic where you'd be able to override any of:

• Icon
• Name (used as the tooltip on the button, as well as in the window menu shown on clicking the title pane app icon)
• Action

[ed-erwin-tf]

Allowing me to override window button icon, name and action could be useful to me. Developers should be careful not to subvert user's expectations, though. Changing the name can be useful when localizing to locales not supported by java or Radiance. Changing action could be useful for this bug.

Yes, I'm only trying Corretto 11 so far. I'll try a few others, but there are so many variables....

One thing that might also be important is "High DPI Auto-Scaling on Windows". Depending on java version and other settings, Windows may or may not auto-scale sizes. This may be why my window is expanding larger than the screen size: i.e. your code assumes windows is not doing the scaling, so you do it yourself. Some versions of java do (and some do not) pay attention to property "sun.java2d.dpiaware".

Behavior was changed in java 8 update 211 and maybe(?) remained the same since. If scaling is 150% or higher, then java asks Windows to auto-scale. https://www.oracle.com/java/technologies/javase/8u211-relnotes.html

[ed-erwin-tf]

Here are details from studies with Coretto 11. The summary in the first comment is much easier to digest, but here are the details:

RadianceResizing.txt

[kirill-grouchnikov]

I'm going to back out that change in Radiance (and Aurora).

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231564 fixed the behavior of JFrame. setMaximizedBounds on multi-monitor setups with high-DPI displays. That fix went into 11.0.8 build of OpenJDK - and looks like the latest Corretto 11 build has it as well.

At this point, I'm not going to do some sort of vendor/version tracking to apply the fix on specific JDK versions. So the incorrect behavior of maximizing a Radiance-decorated window that overlaps the system taskbar will be restored, and future bugs in that area referred to using the latest versions of the JDK.

[ed-erwin-tf]

Thanks. I think this is the correct approach. The JDK should be responsible for this issue.

[ed-erwin-tf]

Kirill has removed the code that computed maximum window bounds because it only works in some JDKs in some systems. I think this is the correct choice. But if you need to do something different in your program, you can override JFrame.setExtendedState() to calculate the max bounds immediately before calling the superclass method.

For example, this works for me to allow me to use Radiance 6.0.1 or 6.5.0, and also fixes Metal LAF to pay attention to Windows Taskbar:

  JFrame frame = new JFrame() {
      @Override
      public void setExtendedState(int state) {
        boolean defaultDecorated = isDefaultLookAndFeelDecorated();
        boolean frameDecorated = getRootPane().getWindowDecorationStyle() == JRootPane.FRAME;
        // determining whether the frame is decorated is tricky.  This works for me right now.  Test for yourself.
        if (defaultDecorated || frameDecorated) {
          // If this frame is decorated, make sure the maximum size
          // is set properly for the screen and its insets.
          // This logic works for Windows with Corretto 11, but different
          // logic may be needed on other systems.
          GraphicsConfiguration gc = getGraphicsConfiguration();
          Insets insets = getToolkit().getScreenInsets(gc);
          Rectangle screenBounds = gc.getBounds();
          Rectangle maxBounds = new Rectangle(
            screenBounds.x + insets.left, screenBounds.y + insets.top,
            screenBounds.width + insets.left - insets.right,
            screenBounds.height + insets.top - insets.bottom
          );
          setMaximizedBounds(maxBounds);
        }
        super.setExtendedState(state);
      }      
    };