Java windows and fonts are huge running in openjdk-11-jre

Bug #1765914 reported by Rocko
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
openjdk-lts (Ubuntu)
Invalid
Undecided
Unassigned
unity-settings-daemon (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

If I run a Java application with oracle-java-8 in an X session, the windows and fonts are all normal size. When I run the same application with openjdk-11-jre, everything is scaled up to double size (see attached image, which shows an application on the left running in Java 8 and the same application on the right running in Java 10 (from the package openjdk-11, not openjdk-10 for some reason).

My normal screen layout is 1920x1080 with two screens, so the command "xrandr -q | awk -F'current' -F',' 'NR==1 {gsub("( |current)","");print $2}'" shows 1920x2160.

One of the screens is 4K, so presumably Java *might* be detecting this and deciding it needs to double everything in size, but this is clearly an error since I'm not even using this mode.

If I set the laptop to use a single external 1920x1080 monitor, it makes no difference - the Java applications are still double the size that they should be.

There's no problem if I run in a Wayland session - the app windows run at a normal size whether in java 10 or 8.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: openjdk-11-jre 10.0.1+10-1ubuntu2
Uname: Linux 4.17.0-041700rc1-generic x86_64
ApportVersion: 2.20.9-0ubuntu6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sat Apr 21 14:12:39 2018
InstallationDate: Installed on 2017-08-16 (247 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: openjdk-lts
UpgradeStatus: Upgraded to bionic on 2017-11-17 (154 days ago)

Revision history for this message
Rocko (rockorequin) wrote :
Rocko (rockorequin)
description: updated
Revision history for this message
Rocko (rockorequin) wrote :

I've attached a comparison of xrandr's output for Wayland and X11. In Wayland, it only shows the currently configured resolution, whereas in X11 it lists all available resolutions and flags the current one with an asterisk.

Perhaps Java is using xrandr and misinterpreting the results when trying to determine dpi?

Revision history for this message
Rocko (rockorequin) wrote :

It looks like the code in src/java.desktop/unix/native/common/awt/systemscale/systemScale.c is reading the dconf /com/ubuntu/user-interface/scale-factor value to determine scaling and using the highest setting. When openjdk is drawing windows too large, this is the value:

$ dconf read /com/ubuntu/user-interface/scale-factor
{'eDP-1': 16, 'HDMI-1': 8}

and if I manually change this to {'eDP-1': 8, 'HDMI-1': 8}, the windows are drawn normal size.

I'm not sure why this was set to 16 in the first place, because gnome-control-center has both monitors set to 100% scaling. Is scale-factor a leftover from Unity?

Revision history for this message
Tiago Stürmer Daitx (tdaitx) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I have been trying to track down which component/application is actually responsible for creating and maintaining /com/ubuntu/user-interface/scale-factor, but so far no luck.

It seems to be related to Unity according to the few Google results I can see, so the question is whether a package failed to remove/move that setting or if OpenJDK should change what it looks at and/or in which order.

OpenJDK currently looks for:
- /com/ubuntu/user-interface/scale-factor
- com/canonical/Unity/Interface/text-scaling-factor
- org/gnome/desktop/interface/text-scaling-factor
in that order, using the first one it finds.

Weirdly enough it does not look for org/gnome/desktop/interface/scaling-factor.

These changes were introduced by JDK-8149115 in commit http://hg.openjdk.java.net/jdk/jdk/rev/a3cc7e551a48 but neither the bug nor the Mailing list discussion state why they picked those items and in this particular order.

Revision history for this message
Rocko (rockorequin) wrote :

Interesting! I would think that it should check if unity is actually running before it looks for the unity variables, and if gnome-shell is running it should just look for the gnome-shell variables.

I did notice that when it was reading the scaling factor of 16 for my laptop monitor and drawing the windows double-size, they stayed double-size when I moved them to the external monitor (with a scaling factor of 8), so openjdk is not taking individual monitor scaling into account.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openjdk-lts (Ubuntu):
status: New → Confirmed
Changed in unity-settings-daemon (Ubuntu):
status: New → Confirmed
Revision history for this message
CarlosRuiz_globalqss (carg67) wrote :

Hi, same issue here, swing applications are unusable because of the big fonts.

For example running SoapUI-5.4.0 results in too big font screen that makes it unusable.

Reading the changset a3cc7e551a48 pointed by Tiago I found a workaround, setting environment variable J2D_UISCALE to 1 makes the trick.

So, I added this at the beginning of soapui.sh and now it seems fine:
export J2D_UISCALE=1

Regards,

Carlos Ruiz

Revision history for this message
Vladimir Petko (vpa1977) wrote :

Retested with SoapUI in lunar - no issue with the font size.

Bionic is EOL, closing the issue as invalid.

Revision history for this message
Vladimir Petko (vpa1977) wrote :

Validated SoapUI in bionic - no issue with the font size.

Revision history for this message
Vladimir Petko (vpa1977) wrote :

openjdk 11.0.19 2023-04-18
OpenJDK Runtime Environment (build 11.0.19+7-post-Ubuntu-0ubuntu118.04.1)
OpenJDK 64-Bit Server VM (build 11.0.19+7-post-Ubuntu-0ubuntu118.04.1, mixed mode, sharing)

Changed in openjdk-lts (Ubuntu):
status: Confirmed → Invalid
Changed in unity-settings-daemon (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.