Menu

#3931 incorrect display scaling on MacOSX Retina (with workaround)

normal bug
closed-fixed
5
2017-03-18
2015-10-11
draeath
No

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.

1 Attachments

Discussion

  • draeath

    draeath - 2015-10-11

    I should mention the example images were taken on a 220 DPI screen.

     
  • Makarius

    Makarius - 2015-10-11

    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

     
  • draeath

    draeath - 2015-10-11

    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
  • draeath

    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
  • Makarius

    Makarius - 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

     
  • draeath

    draeath - 2015-10-11

    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?

     
  • Björn Kautler

    Björn Kautler - 2017-03-18
    • status: open --> closed-fixed
    • assigned_to: Björn Kautler
     
  • Björn Kautler

    Björn Kautler - 2017-03-18

    jEdit 5.4.0 has the NSHighResolutionCapable flag set in the plist

     

Log in to post a comment.