Summary: incorrect DPI scaling with binary, direct launch of jedit.jar works correctly
Version/Environment: jEdit 5.2.0 on OSX El Capitan
java version "1.8.0_60", Java(TM) SE Runtime Environment (build 1.8.0_60-b27), Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
When run with the jEdit.app/Contents/MacOS/jedit binary, scaling does not work correctly. While screen elements and fonts are rendered with the correct size, they appear to have been scaled up and look very ugly and pixelated. When run directly as "java -jar jEdit.app/Contents/Java/jedit.jar, this problem is not present and everything looks great. I have tried every included look&feel and they all exhibit this same behavior. Including a side-by-side screenshot comparison.
From the about screen, when run with the binary OR direct (doesn't change)
jEdit 5.2.0 server-background mode, using Oracle Corporation Java 1.8.0_60
Not familiar with the wrapper being used, so I won't guess as to the cause, but I suspect a JVM argument or environment variable disparity between the executed JRE from the wrapper, and the defaults when java is run direct from the terminal. I only have this one JRE installed.
I should mention the example images were taken on a 220 DPI screen.
I have recently updated to El Capitan on my test machine, but it is rather old, without Retina. Maybe you want to try this alternative bundling of a jEdit-based application: http://www4.in.tum.de/~wenzelm/test/Isabelle_07-Oct-2015/ -- I would be interested how it works on such a recent Mac OS X system.
Concerning the official jEdit.app, my guess is that it lacks the following Info.plist entry:
<key>NSHighResolutionCapable</key>
<string>true</string>
E.g. see http://help.infinitekind.com/discussions/problems/4227-macbook-pro-retina-display-support
Yea, I'd thought it might be that as well, but adding to the plist file didn't appear to change anything. I think that value was used for earlier Apple-supplied JREs. There were patches flying around the Oracle bug tracker back in 2013 about it, I believe.
I'll have a look at that package and see what happens with it. Download from that server is unreasonably slow, but I should be able to report back soon.
EDIT: got it, trying now. I should note it appears to contain a local copy of the JRE along with a whole pile of libraries, so I may not be able to do a 1:1 test with this.
Last edit: draeath 2015-10-11
OK, that Isabelle snapshot worked out-of-the-box. I didn't need to do anything for it to pick up the proper DPI and such.
I went back to jEdit, and took another look through Info.plist. In short, I wasn't able to spot anything. Specifically I removed <key>JVMOptions</key> and it's associated array element, but there was no change. This at least indicate's it's not a parameter you're passing to the JRE (from the plist anyway) that's mucking it up ;)
Last edit: draeath 2015-10-11
OK. For the record: Isabelle_07-Oct-2015 uses
I actually made some experiments to use the more recent fork https://bitbucket.org/infinitekind/appbundler which also supports file associations, but it did not quite work out with an unsigned application.
I actually think that the app bundler is not relevant for the retina problem, and even official jedit 5.2.0 should work with the NSHighResolutionCapable.
Note that an application that has already been "seen" by Mac OS X needs to be updated as described at the end of http://help.infinitekind.com/discussions/problems/4227-macbook-pro-retina-display-support
That did the trick... and it seems doing it via the terminal wasn't enough. Finder seems to do some extra work that it just doesn't tell you about.
So, yes. Inserting NSHighResolutionCapable and shuffling the .app around to invalidate this cached plist works! Looks like a simple fix for future versions, eh?
jEdit 5.4.0 has the NSHighResolutionCapable flag set in the plist