Processing IDE interface too small on high-res Windows displays

[ThexXTURBOXx]

Description

The toolbar and general interfaces of Processing's IDE are too small on 4k screens. The editor is big enough (changable in the configs)

Expected Behavior

Screenshot taken from Processing 3.5.4:
http://prntscr.com/smb7u1
http://prntscr.com/smb9gc

Current Behavior

Screenshot taken from Processing 4.0-alpha1:
http://prntscr.com/smb7eo
http://prntscr.com/smb91d

Steps to Reproduce

1. Open Processing 4 on a 4k screen

Your Environment

• Processing version: 4.0-alpha1
• Operating System and OS version: Windows 10 64 bit

[sampottinger]

Hey there! Thank you for this report. Just to gather some additional information, what does this look like when you use the "automatic" checkbox under interface scale?

[ThexXTURBOXx]

Hey, I am not at my home now. I will report back tomorrow or in 2 days.

[ThexXTURBOXx]

With "automatic" enabled, it just uses 100% and the interface is still too small
Edit: Yes, I restarted Processing after setting it to "automatic"

[sampottinger]

Thanks for writing back and confirming. Unfortunately I don't have access to equipment to easily replicate this but I'll try to help out as soon as I can.

[ThexXTURBOXx]

Okay, thank you very much! Maybe it had something to do with the settings of Windows.
I set the interface scaling in Windows 10 on my 4k monitor to 150%. I don't know, if this helps finding the issue, though.

[sampottinger]

Hey there @ThexXTURBOXx! Great news... I was finally able to get to a large resolution Windows display. #103 should resolve the issue.

[ThexXTURBOXx]

Hey there! Thank you very much! I have built your branch on my computer and tried it out, but it still looks pretty small on my machine:

I have tried setting the interface scale to automatic again and it didn't change it too much (it made it even a little bit worse):

Is there something else I could try?
Im so sorry for bothering you with this 😅

[sampottinger]

Hey there! Not a bother at all. Thank you for your help. I do see the interface scaling in the screenshots you provided. Could you say more about what isn’t working? If you go to 300% do you see the change you expected? Do you see IDE text size change? Thanks!

[sampottinger]

I should mention that I don’t think the dialog boxes scale using the preferences. I could see about switching that but let’s see if the IDE (non-dialog boxes) does the right thing at larger scales.

[ThexXTURBOXx]

Thank you for your help! :)
I see some changes I would expect, but some other things seem to be untouched by that setting. These include the menu items and the dialog boxes:
http://prntscr.com/t8wrgs
http://prntscr.com/t8ws0n (Same thing for e.g. the save-dialog box)
Oddly, sub-menus seem to scale properly:
http://prntscr.com/t8wt67
http://prntscr.com/t8wtbs
Also, it looks to me as the scale would be too big for some items, compared to the Processing 3 IDE:
http://prntscr.com/t8wumf
http://prntscr.com/t8wu9w
Additionally, I think, I have noticed the behavior of dialog boxes in the Processing 3 IDE:
I think, those things (menu, dialog boxes and all other things except the editor and console and so on) really don't scale with the setting, but rather with the Windows 10 settings:
http://prntscr.com/t8wvrq

[sampottinger]

Got it. So I think there's three things here:

• We definitely needed Ensure not trying to use Toolkit zoom before ready. #103 b/c the non-native scaling (preferences option in Processing) might act in ways unintended.
• The rest of the UI doesn't change (if you re-pull Ensure not trying to use Toolkit zoom before ready. #103 the menu bar resizing is removed) as intended behavior. I think it's a reasonable question if it should (I'm kinda of the opinion that it might be a good idea but it hasn't been done in the past, curious to get the community's thoughts).
• Native scaling is "working" per the attached screenshots and the prior decision made in Turn off swing automatic UI scaling for windows. #30.

So, #103 is the only "fix" to bring us back to "expected" behavior. However, we can change expected behavior. For the second point above @ThexXTURBOXx, what are your thoughts? Do you think all of the UI should scale including dialogs (unlike in Processing 3)? Is the interface more usable at that higher zoom for you? Do you prefer the higher zoom or the display scaling?

[ThexXTURBOXx]

Oh, that's a tough one... I pulled your changes and rebuilt it and tested it on my 4k monitor again.
I also tried changing the native scaling of windows to e.g. 300% (I am normally at 150%, but these results are unchanged from those: #102 (comment)). At 300%, this is what the IDE looks like then: http://prntscr.com/t9qnua
So, there still seems to be some kind of problem on my machine. I will try to inspect some of Processing's code if I find some time. Maybe I find something there :)

[sampottinger]

Oh interesting. If I build for windows and post the executable, would you be willing to test it to see if you have the same issue?

[ThexXTURBOXx]

Yes, of course!

[sampottinger]

Cool! I'm getting that prepared over at sampottinger#37. I'll post some new executables soon. Thanks!

[ThexXTURBOXx]

Okay, perfect. No problem and thank you! :)

[sampottinger]

Hey there! #103 is available on an integration branch at https://github.com/sampottinger/processing4 (master) for testing in the context of other open PRs with a community build at https://www.datadrivenempathy.com/processing. LMK if that community build works for you. Thanks!

[ThexXTURBOXx]

Hey there again!
I think, it is the same result as last time:
http://prntscr.com/tdaj2i (150% native scaling, default for 4k displays)
http://prntscr.com/tdaid8 (300% native scaling)

[sampottinger]

Thanks so much @ThexXTURBOXx. Alright, I think I finally dug down to the bottom of this and... it's not fantastic.

So, you are seeing the results of the fix to #31. Re-enabling sun.java2d.uiScale.enabled and everything works well (👍) but only if your scaling is a multiple of 100% (👎) otherwise the fractional text width problem comes back as described in #21 and the editor becomes (arguably) unusable. I tested this with the latest build from adoptopenjdk and an updated version of Windows 10. Indeed, it's still around (😭). It's a little tricky too because the issue is managed in config.xml for Windows for us. Interestingly, while I can't be sure, we might not be the only ones confronting this issue (note the date). It's hard to say where the blame is for this issue (existing in the liminal space that is created in the relationship between Swing and Windows) except to say that it's related to JEP 263 and the fact that there's not a super great way to respond to the screen scaling within the application (as opposed to JVM) layer. I'm not sure why but the JNA way of finding the display scaling isn't reliable... but as far as I can tell is the only way to do it.

So... yikes... Not great. Really, I think the question comes down to accessibility. My recommended approach would be to keep sun.java2d.uiScale.enabled disabled for the reasons discussed in #21 / #31 and then (😬) implementing custom font size based on interface scaling across all the UI so that low vision users can at least use "native" processing scaling for a good experience with support for 150% zoom under the assumption that sun.java2d.uiScale.enabled=false. This is because we can't really guarantee a solution to fractional character width calculation under any other set of configurations.

Alright, so, back to your issue... We still need #103 and I would recommend that it mark this "resolved" but we should open another issue (i'll do that in a moment) about font scaling everything in the IDE based on the user selected processing zoom.

[ThexXTURBOXx]

Thank you very much for digging down so far into the issue!
That's a real bummer... Was sun.java2d.uiScale.enable enabled in Processing 3 then or has there been a major change into GUI/JNA related stuff in JDK 9/10/11?

Also, after looking further into the issues you described and the guys at Jetbrains had as well (I never noticed that back then weirdly enough...) I found a workaround:
http://prntscr.com/tfsq3n

The interface is overall a little bit blurry, but it's better than being very small...
Here is what I did (since my Windows has a German interface, I can't exactly tell the english names for the properties, sorry):

1. Go to <processing4directory>\java\bin, right-click on javaw.exe and select "Properties"
2. Go to "Compatibility" in the menu bar and click on "Change High DPI settings"
3. Turn on "Override High DPI scaling" and set the thing under it to "System"

Since I now have a solid standing point with what the issue might be about, I might even try to dig into this issue myself as well (after my exams at the university of course).
So, thank you very much! :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.