[PATCH] Icons and fonts too small with HIDPI displays

[ian1caldwell@…]

On a 13.3 inch super-high-resolution QHD+ (3200 x 1800) display using windows 8.1 and java version "1.7.0_55" to icons are much to small and some of the layout does not work:

Update:
For a temporary solution to scale the node symbol and text sizes in the map view see the style Styles/HiDPISupport (JOSM version 10018 or newer is required.)

1920x1080:

3200x1800:

[Don-vip]

Could you please attach a screenshot? Thanks.

[ian1caldwell@…]

screen shot at 3200x1800 resolution

[anonymous]

screen shot at 1920x1080 resolution

[ian1caldwell@…]

2 screenshots added with the screen resolution to 3200x1800 and 1920x1080.

1920x1080 is workaround for the icon size but the fonts on the right hand side are still wrong.

[Don-vip]

thanks.

[stoecker]

Will fix it when someone gives me a matching monitor :-)

[Don-vip]

Replying to stoecker:

Will fix it when someone gives me a matching monitor :-)

+1 :D

In the meantime, I'll see if we can reproduce/test this by changing DPI settings with a standard monitor...

[Don-vip]

Looks like High-DPI screens on Windows are not officialy supported by Java itself: see bug ​8029087.

We should wait for proper support first to see if we need to do something or not.

[Don-vip]

See #10343 for another related problem.

[anonymous]

I just tried the external manifest work around mentioned in comment ​#60 on this Eclipse bug, and it seems to resolve the icon sizes -> ​https://bugs.eclipse.org/bugs/show_bug.cgi?id=421383 (I create a java.exe.manifest for the JRE used to run josm-tested.jar)

[maerco@…]

I'm not able to solve the problem.
JOSM is using Javaw should I create the manifest for such exe?

Could you please attach your manifest here?

[peter]

I would appreciate more detailed steps how to proceed with the custom manifest, it is not working for me (win10).

anyway, out of curiosity I tried this approach: unpacked the jar, resized all the icons by 200% and packed it together into a new jar -- but it has not helped me either.

[Don-vip]

HiDPI Graphics on Windows and Linux is covered by ​JEP 263 and may be available in ​Java 9.

[Don-vip]

Latest snapshots of Java 9 contain hidpi support for Linux and Windows, you could give it a try: ​https://jdk9.java.net/download/

[mdk]

#12274 is also about font size on start page and advanced preference table. (Windows and HiDPI display).

[stoecker]

Note there are expert options "iconsize...." now, which set the icon sizes. On HIDPI increasing them may help. Font size should also be modifyable in expert settings already.

I have a HIDPI Linux PC now, so I'll probably take a look at some of the related issues. The final implementation will probably be a HIDPI setting which increases a zoom factor. Let's say HIDPI means 200%, so each font, icon, ... is doubled, but the settings values will remain on the old values. That's much easier than adapting each value individually.

My current idea is to detect any screen > 2000x2000 as HIDPI and set scaling to 200% in this case.

Warning: Any configuration changes you do not will result in REALLY large icons when that is implemented :-) But as I have little time that can be some releases in future.

[Don-vip]

Ticket #12274 has been marked as a duplicate of this ticket.

[stoecker]

Ticket #12447 has been marked as a duplicate of this ticket.

[Klumbumbus]

For a temporary solution to scale the node and text sizes in the map view see the style Styles/HiDPISupport (JOSM version 10018 or newer is required.)

[Don-vip]

Ticket #12727 has been marked as a duplicate of this ticket.

[Klumbumbus]

Ticket #12820 has been marked as a duplicate of this ticket.

[Klumbumbus]

Ticket #12782 has been marked as a duplicate of this ticket.

[Don-vip]

Ticket #12886 has been marked as a duplicate of this ticket.

[strump]

I have a notebook with HiDPI monitor and I suffer from poor JOSM support of my system. I tested on Windows 10, JDK 1.8u74. I think we could fix this problem without waiting for Java 9.

First to detect a monitor with hight pixel density next methods could be used:

    /**
     * Returns coefficient of monitor pixel density. All hardcoded sizes must be multiplied by this value.
     * @return float value. 1 - means standard monitor, 2 and high - "retina" display. 
     * @since XXX
     */
    public static float getPixelDensity() {
        int pixelPerInch = Toolkit.getDefaultToolkit().getScreenResolution();
        return (float)(pixelPerInch/96.);
    }

    public static boolean isHiDPI() {
        return getPixelDensity() >= 2f;
    }

    public static int getSizeDpiAdjusted(int size) {
        int pixelPerInch = Toolkit.getDefaultToolkit().getScreenResolution();
        return size * pixelPerInch / 96;
    }

On my PC getPixelDensity() returns value 2.5.

These methods could be used to update all sizes (width, height, font size, icon dimensions). For example method GuiHelper.getTitleFont() must be rewritten to:

public static Font getTitleFont() {
    return new Font("SansSerif", Font.BOLD, getSizeDpiAdjusted(23));
}

As far as I can see, font sizes are mostly corrent. For example add tag dialog has no glitches on HiDPI screen except small icons. Only HTM formatted text in JosmEditorPane needs CSS styling. The main problems are:

1. Icon sizes - we need to resize each icon as done in method SideButton.getScaledImage(...). Or we could have each icon in two sizes and select PNG file depending on monitor DPI.
2. Lot of UI components must be resized according to DPI: tables, trees, progress bars, etc.
3. Update JosmEditorPane default CSS style to set right font sizes for HiDPI monitors.
4. Update windows sized (cosmetic fix). For example "Search menu items" dialog looks very tiny with default width and height and I manually resize it each time I start JOSM.

I was investigating this issue and could achieve next:

Here I've updated default height of a title in ToggleDialog class, resized icons on a buttons and added tagTable.setRowHeight(...); membershipTable.setRowHeight(...); to the PropertiesDialog class.

I think HiDPI issue could be solved without waiting for Java 9. It requires a lot of changes but I'm expirienced professional Java developer. I can fix this ticket and test on my PC.

[Don-vip]

Great news! I'm looking forward for a patch then :) thanks for your help this is highly appreciated as we don't have hidpi hardware.

[stoecker]

In theory nearly nowhere in the source there should be hardcoded sizes. We didn't reach that goal yet :-) See also #10684 which did a lot to get the image sizes handled in one place. Also for fonts there probably should be a similar one place handling.

My plan also was to use a common scaling factor. I wouldn't make this hardcoded based on the screen, but on preferences settings. The default for this setting can then be the solution you provide above, so it works from start.

Note: In JOSM we usually use many preferences for changing behaviour, but only a small amount of these is really exposed to the user (only when it makes sense for the user to change the defaults).

My idea was to leave all the size settings (icons, fonts, ...) as they are now and have a scaling factor in the prefs with automatic HDPI detection to let the user choose (like e.g. KDE has) - but I don't spend much time for JOSM ATM. Seems you ideas go much into the same direction. That way we don't need different sets of settings for different screens. Maybe that does not work completely, as not all elements are really scaled similar. But there should be a centralized place to handle that and components are only calling getWhatEverSize() instead of duplicating the calculations everywhere.

Same like Vincent I'm happy to see patches. If it affects you, you're a good candidate to fix it :-)

[strump]

Ok, I'll try to fix this issue and send you a patch. But it wouldn`t be soon. And I have some questions:

1. As I understood, you want to have some global static method int getWhatEverSize(int) to convert "virtual" size to a "real" size. And if someone wants to scale UI then this method should return properly scaled values. Is it correct?

2. Scaling factor should be stored in settings. DPI factor is default value for scaling factor. But one can set scaling by hand. Is it correct?

3. May I use your wiki to track my progress? I need to store my ideas and trace all places affected by UI scaling feature.

[stoecker]

Replying to strump:

Ok, I'll try to fix this issue and send you a patch. But it wouldn`t be soon. And I have some questions:

1. As I understood, you want to have some global static method int getWhatEverSize(int) to convert "virtual" size to a "real" size. And if someone wants to scale UI then this method should return properly scaled values. Is it correct?

No, I think you misunderstood me. For whatever size in the code used more than once there should be a common place with get...Size() for use. E.g. getTitleBarSize(). This moves the logic of size computations into one (or a few) places. E.g. The ImageProvider class has ImageSizes, which is (should be) the central place for getting image size. Thus whatever the future may bring we only need to change one place. This place then should do the size adaption according to whatever method is proper.

Maybe a new class "GuiSizes" to cover font and GUI element sizes would be enough. In ImageSizes you also see that beside the fact that some sizes are equal I introduced multiple names in case they will differ in future.

If that does not work, feel free to adapt the idea as necessary.

2. Scaling factor should be stored in settings. DPI factor is default value for scaling factor. But one can set scaling by hand. Is it correct?

Nearly. Configs are only stored, when they differ from the default. If you do Main.pref.getInteger("gui.scalefactor", xxx.getDefaultScale()) then this allows it in principle to allow changing by user. In practice it simply takes the default you pass as second argument. Value should be in percent I think. I've seen that for KDE.

Maybe that does not work as I think and the better solution would be a choice between different presets? I'm only telling you ideas. If they don't work you need to find another solution :-)

3. May I use your wiki to track my progress? I need to store my ideas and trace all places affected by UI scaling feature.

Wiki is bad for that. Better use one (or more) tickets for it. Also please split changes into smaller parts. We're continuously integrating such changes. That gives you a proper feedback and we don't have trouble with a large block of changes which we may disagree with. Only requirement is that software keeps working after each changeset. Also if you loose interest (which I don't hope, HDPI gets more and more important) your work until that point is not lost...

[strump]

Hi,

Here's the first patch: ​hidpi_patch_1_images.patch.

I've created draft documentation with some technical aspects: ​HiDPI_JOSM_support_description.rtf

Was changed:

• Added static class GuiSizesHelper to get screen resolution and make calculations of real sizes.
• All icons and images are loaded through ImageProvider class.
• No hardcoded image sizes. All dimension calculations are moved to ImageProvider. While ImageProvider makes conversion from virtual size to real size.
• All image resizes must be done using util methods ImageProvider.getScaledIcon(...).
• ImageProvider.ImageSizes enum now has two fields: virtualWidth and virtualHeight.

After you apply this patch

Expected result on standard screen: nothing changed, at all. All pixels on the same places.

Expected result on HiDPI screen: all icons and images are scaled according to DPI settings. Some UI glitches are still present. But images must be scaled right.

Here's screenshots to compare: ​Screenshots

What's left to do:

• Scale UI components (tables, scroll bars, progress bars, windows sizes, etc.);
• Scale fonts;
• Set up scaling factor from settings;
• Scale vector map (I have no idea how it must be done).

Waiting for review.

P.S. Is there any way to attach files? Now I store files in my Dropbox folder and put links to them. Maybe there's a better way?

[stoecker]

-            new ImageIcon(ICON_OPEN.getImage().getScaledInstance(ICON_SMALL_SIZE, ICON_SMALL_SIZE, Image.SCALE_SMOOTH));
+            new ImageProvider("dialogs/notes", "note_open").setSize(ICON_SMALL_SIZE, ICON_SMALL_SIZE).get();

That seems wrong. Should be setSize(ImageProvider.ImageSizes.WHATEVER) WHATEVER beeing SMALLICON I assume?

     final class SaveAndProceedAction extends AbstractAction implements PropertyChangeListener {
-        private static final int ICON_SIZE = 24;
         private static final String BASE_ICON = "BASE_ICON";
         private final transient Image save = ImageProvider.get("save").getImage();
         private final transient Image upld = ImageProvider.get("upload").getImage();
+        private final transient int ICON_SIZE = save.getWidth(null);
         private final transient Image saveDis = new BufferedImage(ICON_SIZE, ICON_SIZE, BufferedImage.TYPE_4BYTE_ABGR);
         private final transient Image upldDis = new BufferedImage(ICON_SIZE, ICON_SIZE, BufferedImage.TYPE_4BYTE_ABGR);

That also looks suspicious. Calls should be similar to the above ones using ImageSizes class. Note, that unmodified variant is also not ok :-)

Give me some time to understand what you did. On first view it looks sensible, but I don't fully understand it yet. P.S. attaching patches here at the ticket is preferred.

[stoecker]

The Link to do attachments is below the ticket and above comments.

Please do patches always in josm directory, not somewhere in the subdirectories. The patch tool can strip common path parts, but not add path. See here: DevelopersGuide/PatchGuide.

[stoecker]

In 10356/josm:

see #9995, see #10684 - remove more hardcoded places of images

[stoecker]

Last changeset makes the SideButton changes obsolete. :-)

[stoecker]

In 10357/josm:

see #9995, see #10684 - remove more hardcoded places of images

[stoecker]

In 10358/josm:

see #9995 - improve handling for HIDPI screens, patch by strump (modified by me)

[stoecker]

In 10359/josm:

see #9995 - overlooked part of the code

[stoecker]

I'm not yet totally happy with that code yet, but it's better than before. The HIDPI stuff is restricted to 3 classes ATM and that means it can be changed easy.

Notes:

• Please more care with the JavaDoc :-)
• In the changes I did you see, that I don't like the GuiSizesHelper to be exposed outside Images classes.
• I removed your icon scale function and instead fixed the code to properly handle the image creation (except the deprecated part in SideButton)
• Same with the empty icon from plugins.
• My code from yesterday shows how to replace all these SMALL_ICON places.
• I stripped two or three places, where I thought that your fixes go into wrong direction (instead of using ImageProvider properly you tried a workaround).

JOSM development was long with changing authors and approaches. Thus ImageProvider is not used everywhere where it should be. The HIDPI stuff is a a good reason to fix that.

[strump]

Replying to stoecker:

The Link to do attachments is below the ticket and above comments.

I haven't noticed the elephant at all.

Please do patches always in josm directory, not somewhere in the subdirectories. The patch tool can strip common path parts, but not add path. See here: DevelopersGuide/PatchGuide.

I created patches with TortoiseSVN but it corrupted file paths. I will do it from console next time.

[strump]

Replying to stoecker:

I'm not yet totally happy with that code yet, but it's better than before. The HIDPI stuff is restricted to 3 classes ATM and that means it can be changed easy.

Notes:

• Please more care with the JavaDoc :-)
• In the changes I did you see, that I don't like the GuiSizesHelper to be exposed outside Images classes.

I thought that GuiSizesHelper would be used to resize UI components with respect to screen DPI. For example GuiSizesHelper.getRowHeight() would return height in pixeles for current screen.

• I removed your icon scale function and instead fixed the code to properly handle the image creation (except the deprecated part in SideButton)
• Same with the empty icon from plugins.

Yes, SideButton is a challenge. Each Action should have "ImageResource" attribute. It's a long way to update them all.

• My code from yesterday shows how to replace all these SMALL_ICON places.
• I stripped two or three places, where I thought that your fixes go into wrong direction (instead of using ImageProvider properly you tried a workaround).

JOSM development was long with changing authors and approaches. Thus ImageProvider is not used everywhere where it should be. The HIDPI stuff is a a good reason to fix that.

I'm little lost with patch approve status. What's next step? Should I fix NotesDialog and SaveAndProceedAction as you mentioned above? Or should I fix all Actions by adding call to ImageResource.getImageIcon? Or I could leave ImageResources as is and move to tables, dialogs and other UI components stuff?

P.S. I don't like name of method ImageResource.getImageIcon. It actually returns nothing. Maybe generateImageIcon ot attachToAction is better?

[stoecker]

Replying to strump:

Replying to stoecker:

I'm not yet totally happy with that code yet, but it's better than before. The HIDPI stuff is restricted to 3 classes ATM and that means it can be changed easy.

Notes:

• Please more care with the JavaDoc :-)
• In the changes I did you see, that I don't like the GuiSizesHelper to be exposed outside Images classes.

I thought that GuiSizesHelper would be used to resize UI components with respect to screen DPI. For example GuiSizesHelper.getRowHeight() would return height in pixeles for current screen.

That's ok. But when it's possible to hide in an utility class (ImageProvider) it should be hidden :-) You're right, that for other things that will not be possible.

• I removed your icon scale function and instead fixed the code to properly handle the image creation (except the deprecated part in SideButton)
• Same with the empty icon from plugins.

Yes, SideButton is a challenge. Each Action should have "ImageResource" attribute. It's a long way to update them all.

Not so much. SideButton should only be used in the dialogs visible on right screen. Everywhere else it should be replaced by JButton. After fixing the obvious cases we'll simply change the Main.warn() into an exception, then we'll get noticed of the remaining cases very fast.
Or maybe first always scale them to 100x100 for visibility :-)

• My code from yesterday shows how to replace all these SMALL_ICON places.
• I stripped two or three places, where I thought that your fixes go into wrong direction (instead of using ImageProvider properly you tried a workaround).

JOSM development was long with changing authors and approaches. Thus ImageProvider is not used everywhere where it should be. The HIDPI stuff is a a good reason to fix that.

I'm little lost with patch approve status. What's next step? Should I fix NotesDialog and SaveAndProceedAction as you mentioned above? Or should I fix all Actions by adding call to ImageResource.getImageIcon? Or I could leave ImageResources as is and move to tables, dialogs and other UI components stuff?

What you want to do. All of this needs to be done. As JOSM admins we only give the direction and check results. We don't tell contributors what they have to do.

I'd appreciate though, when you try to finish one field first. E.g. you could provide a patch doing the non-controversial stuff following the established methods of the last patches by you and me and another patch for the things I rejected on first try. Then I can checkin the first one without much review and only need to focus on the second one. I'd would be really strange if on your first try to contribute that much I could accept everything without changes. :-)

P.S. I don't like name of method ImageResource.getImageIcon. It actually returns nothing. Maybe generateImageIcon ot attachToAction is better?

I agree that's suboptimal setImageIcon(), attachImageIcon? Seems not to be used outside core yet, so we can fix it easy.

[strump]

Replying to stoecker:

I'm little lost with patch approve status. What's next step? Should I fix NotesDialog and SaveAndProceedAction as you mentioned above? Or should I fix all Actions by adding call to ImageResource.getImageIcon? Or I could leave ImageResources as is and move to tables, dialogs and other UI components stuff?

What you want to do. All of this needs to be done. As JOSM admins we only give the direction and check results. We don't tell contributors what they have to do.

I'd appreciate though, when you try to finish one field first. E.g. you could provide a patch doing the non-controversial stuff following the established methods of the last patches by you and me and another patch for the things I rejected on first try. Then I can checkin the first one without much review and only need to focus on the second one. I'd would be really strange if on your first try to contribute that much I could accept everything without changes. :-)

I'm asking because I'm not sure if you finished review of my previous patch. I've found the you left hardcoded image sizes in AboutAction, GenericSessionExporter. Anyway, I agree we need to finish with icons scaling before going further.

I've attached patch hidpi_patch_2_images_leftovers.patch. Was changed:

• renamed ImageResource.getImageIcon(AbstractAction), ImageResource.getImageIcon(AbstractAction, boolean) to attachImageIcon(...)
• removed hardcoded image sizes in AboutAction, GenericSessionExporter, and NotesDialog. In NotesDialog I've added static block to free ImageProvider`s. I'm not sure if it's right way.
• added two methods ImageProvider.getDisabledIcon(), ImageProvider.getDisabledImage() to generate disabled (grayed out) images and icons (maybe some caching is needed);
• added static method ImageProvider.joinImages(Image[]) to join multiple images in a single row. It's used in SaveLayersDialog.SaveAndProceedAction to display three icons on one button.
• updated SaveLayersDialog.SaveAndProceedAction class to incapsulate image editing logic in ImageProvider class.

Problems:

• Hardcoded icon size in NotesDialog.ICON_SMALL_SIZE must be eliminated;
• SideButton still must be fixed.

Wayting for review :)

[stoecker]

In 10369/josm:

see #9995 - patch by strump - improve HIDPI

[stoecker]

Oh, you took too long to write the text :-) Already applied much of the patch.

I left out two parts:

NotesDialog: I don't like the hardcoded stuff, you're on the right track, but not yet there.

SaveLayersDialog: Also the right approach, but not yet there. We did handle the overlay extra previously and then I did a lot to handle it alike to setWidth(), .... So I think this should be done right from start:

• make a setDisabled() for ImageProvider, which only affects the image finally when really output is done
• use addOverlay() for joining (e.g. starting with an empty image).

At the end that means you can use attachImageIcon() - maybe with an option to keep the aspect ratio...

[stoecker]

I'm asking because I'm not sure if you finished review of my previous patch. I've found the you left hardcoded image sizes in AboutAction, GenericSessionExporter. Anyway, I agree we need to finish with icons scaling before going further.

Hmm. Maybe an error on my side or patch did not apply.

[stoecker]

Regarding Notes: ImageProvider has caching already. Maybe simply the static variables can be removed completely.

[strump]

Replying to stoecker:

NotesDialog: I don't like the hardcoded stuff, you're on the right track, but not yet there.

Dirk, you mean I need to remove NotesDialog.ICON_SMALL_SIZE ? And what's about static fields initialization: ICON_OPEN, ICON_OPEN_SMALL, ICON_CLOSED, etc. ? Do you have any remarks to my solution in "hidpi_patch_2_images_leftovers.patch"?

SaveLayersDialog: Also the right approach, but not yet there. We did handle the overlay extra previously and then I did a lot to handle it alike to setWidth(), .... So I think this should be done right from start:

• make a setDisabled() for ImageProvider, which only affects the image finally when really output is done
• use addOverlay() for joining (e.g. starting with an empty image).

At the end that means you can use attachImageIcon() - maybe with an option to keep the aspect ratio...

setDisabled() method is a good idea (maybe with setEnabled() and setEnabled(boolean)). But I don't understand addOverlay() method semantic. Could you give an example how joining of three icon will look like in the method SaveLayersDialog.SaveAndProceedAction.redrawIcon() ?

[stoecker]

I don't have access to my SVN today, so only some comments.

In NotesDialog I probably would remove all the icon storage and simply call ImageProvider at the places, where the icons are used.

For addOverlay() you pass an ImageProvider and relative offsets (e.g. you could provide 0,0,1,0.333 0,0.3333,1,0.66666 0,0.6666,1,1 to join 3 images. At least that is what I remember.

[bastiK]

In 10392/josm:

see #9995 - add advanced preference value 'gui.scale'

can be set to test hdpi display or in case the screen resolution is not recognized correctly by the system

[bastiK]

I've tried with a standard display and custom scale value of 2.0:

The map display still needs some attention as only the icons are scaled, but not the lines, text and other features. A temporary fix would be to turn off the scaling specifically for map icons, so the map looks as before. Then later prepare a patch that scales the entire map properly.

[strump]

One more patch :)

• Removed static fields from NotesDialog;
• Added overloaded method ImageProvider.get(...) with additional ImageSizes argument. This will simplify image loading;
• Updated SideButton constructor to show warning "Old style SideButton usage for action ...". It's strange that constructor with two arguments is always called with "false" as second argument;
• Added "isDisabled" property to ImageProvider. When isDisabled == true image is generated in grayscale;
• Improved NoteLayer. Removed hardcoded NotesDialog.ICON_SMALL_SIZE constant. This fixes bug with notes rendering (see attached screenshots: 5_Note_default.png, 5_Note_hidpi_buggy.png, 5_Note_hidpi_fixed.png).

Problem with hardcoded valies in SaveLayersDialog.SaveAndProceedAction. You propose addOverlay() metod to mix multiple icons on one canvas. Your solution looks like overengeneering for me. Do we need to implement such image layout mechanism? I think it's too complicated approach to solve our problem. We just need to put three icons on a single button. I think we could extend JButton to display multiple icons.

[stoecker]

I'll have a look at this later.

About your addOverlay() question. Why implement? It's already there - I did this last year for the cases where we use overlays. We only need to use it in this case, as it already takes care of the necessary resizing stuff. You simply call it with the overlay images providers and the relative size and positions to the original image. In this case original image should be an empty image which is 3 times wider than high.

[strump]

Replying to bastiK:

The map display still needs some attention as only the icons are scaled, but not the lines, text and other features. A temporary fix would be to turn off the scaling specifically for map icons, so the map looks as before. Then later prepare a patch that scales the entire map properly.

Thanks for testing. As I mentioned earlier in comment icons scaling is the first stage. We also need to handle fonts, UI components, windows sizes and vector map scalling. This issues is far from finishing.

[stoecker]

In 10428/josm:

see #9995 - patch mainly by strump - improve HIDPI behaviour

[stoecker]

I moved the disabled stuff to the right place and added some more attachImageIcon() calls, but otherwise that was mainly your patch :-)

[stoecker]

P.S. In NoteLayer. Can't the GuiSizesHelper calls be prevented? E.g. By simply using the size of the icon after it has been assigned?

Otherwise it would be good, when the call could be hidden in the ImageSizes class.

[Don-vip]

Ticket #13007 has been marked as a duplicate of this ticket.

[stoecker]

In 10484/josm:

see #9995 - don't expose GuiSizesHelper for image purpose

[Polarbear-j]

I was upgrading from an old (March18) version to 10501 today, and found all icons, buttons and window buttons blown up to at least double size, and pixelised, on my Retina/Powerbook Mac OS X 10.11.4. I tried to half all settings with "icon" in their names, which only helps for some of them, still the window buttons among others are huge and keep the titlebars larger than the content.

So I found here that lot of work is going on on this issue, but have reverted myself to the recent stable.

However I would be available if any tests on this machine are needed.

[stoecker]

Replying to Polarbear-j:

I was upgrading from an old (March18) version to 10501 today, and found all icons, buttons and window buttons blown up to at least double size, and pixelised, on my Retina/Powerbook Mac OS X 10.11.4. I tried to half all settings with "icon" in their names, which only helps for some of them, still the window buttons among others are huge and keep the titlebars larger than the content.

Not all. A few (the SVG ones) should not be pixelated :-)

So I found here that lot of work is going on on this issue, but have reverted myself to the recent stable.

Setting gui.scale to 1 should revert the effect completely. No need to change other settings. Maybe also experiment with values between 1 and 2.

[Klumbumbus]

I thought that we could ask the osm community to help us to transform the png icons to svg. Something like a wiki page where we provide the icons we want to have transformed and the users can upload their work. Any thoughts?

[Polarbear-j]

The carto style made a big effort recently in converting to svg. Maybe lots of icons can be reused, also improving recognisability?
​https://github.com/gravitystorm/openstreetmap-carto/tree/master/symbols

[Polarbear-j]

Setting gui.scale to 1

Was set to default=0.0, does that mean automatic? 1 works well, 2 brings the big icons back. And yes, when the pixel shock is over, I find quite a lot sharp ones :-)

Probably that setting needs to be visible in the Look and Feel tab in the release (with a hint that it might require restart).

BTW, what controls the size of the left buttonbar in the Preferences window - that is always too small in the MacOS version, while they are quite large on my Linux machine?

[bastiK]

As demonstrated in the screenshot above, the map display in hi-dpi mode is inconsistent. I think it should not be released as a tested version like this. A suggested fix is to change the default value of gui.scale from 0 (auto-detect) to 1, disabling the new features temporarily. For the development versions after the release, it should be switched back, in order to get more user feedback.

[stoecker]

Replying to bastiK:

As demonstrated in the screenshot above, the map display in hi-dpi mode is inconsistent. I think it should not be released as a tested version like this. A suggested fix is to change the default value of gui.scale from 0 (auto-detect) to 1, disabling the new features temporarily. For the development versions after the release, it should be switched back, in order to get more user feedback.

I'm ok with this.

[stoecker]

Probably that setting needs to be visible in the Look and Feel tab in the release (with a hint that it might require restart).

Seems reasonable. Yes.

BTW, what controls the size of the left buttonbar in the Preferences window - that is always too small in the MacOS version, while they are quite large on my Linux machine?

As far as I remember there was/is a Java bug which forces these icons to a certain size on some systems (MacOs?). There is a bug entry in JOSM for this I believe.

[Klumbumbus]

I tested on standard dpi screen with gui.scale=2. It seems some icons blew up twice:

• Some icons in the edit toolbar left (also lasso mode, which is not sown in the screenshot)
• The icons in the statusbar down
• OK or Close Buttons in e.g. About JOSM window or statusreport window

Screenshot with second JOSM instance with default settings as comparison:

Window with 3 different sizes:

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-06-29 21:32:31 +0200 (Wed, 29 Jun 2016)
Build-Date:2016-06-30 01:34:02
Revision:10502
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10502 de) Windows 7 32-Bit
Memory Usage: 385 MB / 742 MB (156 MB allocated, but free)
Java version: 1.8.0_91-b14, Oracle Corporation, Java HotSpot(TM) Client VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=54497, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

Plugins:
- AddrInterpolation (32158)
- DirectDownload (32158)
- DirectUpload (32158)
- HouseNumberTaggingTool (31926)
- Mapillary (32396)
- OpeningHoursEditor (32158)
- Tracer2 (32158)
- apache-commons (32158)
- apache-http (32158)
- buildings_tools (32158)
- editgpx (32263)
- imagery_offset_db (32158)
- log4j (32158)
- measurement (32324)
- photo_geotagging (32158)
- photoadjust (32158)
- pt_assistant (32457)
- reverter (32158)
- tag2link (31923)
- tagging-preset-tester (32158)
- terracer (32158)
- todo (29154)
- turnlanes-tagging (1466175713)
- turnrestrictions (32386)
- undelete (32158)
- utilsplugin2 (32158)
- wikipedia (32182)

[Klumbumbus]

The icon in the windows task bar becomes pixelated.
Left: gui.scale=2
Right: default setting

[bastiK]

In 10505/josm:

see #9995 - change default gui scale from 'auto' (0) to 1.0 for stable release

[anonymous]

Hi. I was out of Internet for some time and here's new patch:

1. stoecker, in commit 10428 you've modified ImageResource construcstor and inserted line:

    baseImage = scaleBaseImageIfNeeded(img);

This modification caused problems with overscaled images reported by Klumbumbus. I suppose that baseImage field holds original unmodified image as it's loaded from a file. And all dimension calulations are made based on this field. The fix is to use baseImage = img. This will solve problems with twice scaled icons.

2. SaveLayersDialog with three icons on a single button is fixed. I've created EmptyImageProvider class to generate empty (transparent) images. And also used addOverlay() method to combine three images in a row.

3. When I've started HiDPI images refactoring I thought that all images allover JOSM will be scaled automatically. But there's place where image must be loaded from PNG and passed with no changes: app icons in MainFrame.initialize(). JOSM logo must be loaded and passed to setIconImages() as it is. So I've added method ImageProvider.getSourceImage() for that purpose.

One more question. There are two methods in ImageResource class:

    public void attachImageIcon(AbstractAction a);
    public void attachImageIcon(AbstractAction a, boolean addresource);

The second one is always called with addresource=true. Maybe we should remove second method and replace all call with the first method? I suppose we could have single method attachImageIcon(AbstractAction a) with additional line:

    a.putValue("ImageResource", this); //Without conditions

[bastiK]

Great work!

Instead of

new ImageProvider("logo_16x16x32").getSourceImage();

a syntax like the following could be more powerful:

new ImageProvider("logo_16x16x32").setScaleMode(ScaleMode.OFF).get();

since it allows to add max width / height, disabled mode in case it is required and it supports loading the source image in a background thread (getInBackground(...)). If we like to turn off scaling for map images, all of this is needed.

[stoecker]

Replying to bastiK:

Great work!

Instead of

new ImageProvider("logo_16x16x32").getSourceImage();

a syntax like the following could be more powerful:

new ImageProvider("logo_16x16x32").setScaleMode(ScaleMode.OFF).get();

since it allows to add max width / height, disabled mode in case it is required and it supports loading the source image in a background thread (getInBackground(...)). If we like to turn off scaling for map images, all of this is needed.

Is this still needed? Wasn't there an improvement in Java 7 or 8 regarding the handling of the logo icon? I remember something related.

[stoecker]

Replying to anonymous:

Hi. I was out of Internet for some time and here's new patch:

1. stoecker, in commit 10428 you've modified ImageResource construcstor and inserted line:

    baseImage = scaleBaseImageIfNeeded(img);

This modification caused problems with overscaled images reported by Klumbumbus. I suppose that baseImage field holds original unmodified image as it's loaded from a file. And all dimension calulations are made based on this field. The fix is to use baseImage = img. This will solve problems with twice scaled icons.

I had a bad feeling when I changed the constructor. Now I know why. I should listen to my feelings. :-)

I'll have a look at the changes soon.

[Don-vip]

JDK8u102 contains HIDPI fixes, please make sure the tests are done with this version of Java:
​http://www.oracle.com/technetwork/java/javase/2col/8u102-bugfixes-3021768.html

[Klumbumbus]

I just noticed that we have svg versions for a lot of our preset/map icons at ​https://trac.openstreetmap.org/browser/subversion/applications/share/map-icons/svg. I will replace our png with these svg icons.

[stoecker]

Note: Patch is not forgotten, only delayed...

If somebody else will step in until I have time again, please do so.

[anonymous]

Is there a build with the latest experimental patch somewhere to use meanwhile?
Thanks

[simon04]

Milestone renamed

[anonymous]

FYI it seems like Java 9 is now working
I am starting with
GDK_SCALE=2 /usr/lib/jvm/java-9-jre/jre/bin/java -jar josm-tested.jar

Just be aware that you might still run into some bugs

[Don-vip]

Milestone renamed

[solitone]

I also confirm that with Java 9 it does work nicely, provided you launch it with GDK_SCALE=2, for instance:

GDK_SCALE=2 java -jar josm.jar

Preference entry gui.scale needs to be set to default value 1.

[solitone]

A recent upgrade in java 9 has broken something in my system (debian GNU/linux stretch), and josm won't work anymore with java 9. The culprit was the upgrade of the packages oracle-java9-installer and oracle-java9-setdefault, which two days ago got upgraded from ver. 9b140+9b140arm-1~webupd8~3 to 9b149+9b149arm-1~webupd8~0. I confirm that downgrading to 9b140+9b140arm-1~webupd8~3 makes JOSM work again.

Here's the error I get with ver. 9b149+9b149arm-1~webupd8~0:

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2017-01-02 00:53:29 +0100 (Mon, 02 Jan 2017)
Revision:11427
Build-Date:2017-01-02 02:33:21
URL:http://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (11427 en) Linux Debian GNU/Linux testing (stretch)
Memory Usage: 372 MB / 1974 MB (358 MB allocated, but free)
Java version: 9-ea+149, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 2560x1600
Maximum Screen Size: 2560x1600

Last errors/warnings:
- E: Handled by bug report queue: java.lang.reflect.InaccessibleObjectException: Unable to make field private static java.util.ResourceBundle java.awt.Toolkit.resources accessible: module java.desktop does not "opens java.awt" to unnamed module @73e22a3d


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: main (1)
java.lang.reflect.InaccessibleObjectException: Unable to make field private static java.util.ResourceBundle java.awt.Toolkit.resources accessible: module java.desktop does not "opens java.awt" to unnamed module @73e22a3d
	at java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:427)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:201)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
	at org.openstreetmap.josm.tools.Utils.lambda$setObjectsAccessible$0(Utils.java:1463)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at org.openstreetmap.josm.tools.Utils.setObjectsAccessible(Utils.java:1461)
	at org.openstreetmap.josm.data.Preferences.updateSystemProperties(Preferences.java:1429)
	at org.openstreetmap.josm.data.Preferences.load(Preferences.java:662)
	at org.openstreetmap.josm.data.Preferences.init(Preferences.java:763)
	at org.openstreetmap.josm.gui.MainApplication.main(MainApplication.java:255)

[Don-vip]

Replying to solitone:

A recent upgrade in java 9 has broken something in my system

this has been solved through #14211

[Don-vip]

Ticket #8764 has been marked as a duplicate of this ticket.

[bastiK]

Ticket #15125 has been marked as a duplicate of this ticket.

[Klumbumbus]

JOSM is now JAVA 9 ready (see #11924). Everyone with high dpi screen might test java 9 and give feedback here if something has improved regarding scaling.

[bastiK]

Can confirm, it works with Java 9 on Linux when GDK_SCALE=2 is set as environment variable (tested on normal low-resolution screen).

Remaining issues:

• GUI-icons are scaled up x2, even though the image is available in SVG format and we could provide a better resolution.
• The mapview area is simply scaled up as well: Same issue with POI-icons; lines and text are somewhat blurry. (It could be much more crisp.)
• There is a ticket about background imagery for hires display. Probably this isn't working as well.

[bastiK]

The attached patch solves the first issue.

One drawback is that java.awt.image.BaseMultiResolutionImage is Java 9 API. When the patch is applied, Java 9 will be required to compile JOSM. The binary .jar file then runs with both Java 8 and 9 (but no HIDPI-support with Java 8).

[Don-vip]

Replying to bastiK:

When the patch is applied, Java 9 will be required to compile JOSM.

I have (unsurprisingly) already thought about that. The Java 9 migration could happen a lot sooner than the java 8 migration last year:

• openjdk-9 is already available in current Ubuntu LTS (xenial), althought it is an outdated development version (b114)
• openjdk-9 latest version (b181) is already available in Ubuntu 17.10 (artful)

We just have to see if the final version of openjdk-9, once released in September, is backported to oldest Debian/Ubuntu versions (it could happen for security concerns). If it's the case, we could technically migrate as soon as it's backported. If not we must wait at least the next Ubuntu LTS in April 2018.

[bastiK]

Okay, sounds good! Only, in this particular case, a full migration to Java 9 is not even necessary.

We can make the HIDPI-fixes using Java 9 API a soft dependency. I.e. if the user is running JOSM with Java 9, they will benefit from the patch. If they are running Java 8, HIDPI isn't working in the first place, so no need to fix it up. The attached patch is fully functional in this regard.

The only practical difference will be, that developers need a Java 9 compiler to build JOSM.

On the other hand, the issues that will be fixed aren't all that serious. It is more technical pride than necessity: If we ship .svg images, we shouldn't display the image blurry with 2x2 pixel blocks. But if a full Java 9 migration is done in about 6 months anyway, we could just wait for that and save the hassle.

[Don-vip]

okay. Well as there is a single class/method called, it would be simpler to search it by reflection. This way we can keep Java 8 as compiler, and the class MRImage is not needed.

[bastiK]

Good point, this would be easier. The patch works as a proof-of-concept, but it wastes memory. So maybe there will be more references in the revised version.

[Klumbumbus]

A bit Java 9 HDPI feedback in ​german forum

[Don-vip]

is it good or bad? :)

[Klumbumbus]

The last statement is "I go back to good old Java 8 for now" ;)

[bastiK]

It was good feedback, as one user tested Java 9 on HDPI display, pointed out the problems and provided screenshots. Apparently, on Windows it is possible to have a scale factor of 1.5 for the icons and 1.0 for the text. The blur problem is even more pronounced than with scale factor 2.0, we need to do something about it.

[bastiK]

Attached patch (hidpi-mapview.patch​) fixes the blur in the mapview area (work in progress).

In HiDPI-mode (GDK_SCALE=2), a MapView of 800x600 screen pixels will report its own dimension as half the size (MapView.getWidth() => 400). Additionally, in MapView.paint(Graphics g), the Graphics2D g has an initial transform that scales both dimensions by 2 ((Graphics2D)g).getTransform() => AffineTransform[[2.0, 0.0, 0.0], [0.0, 2.0, 0.0]]).

As a result, we create a temporary image of size 400x300. After all layers have painted on this temporary image, it is drawn onto the MapView with zoom factor 2. It can be expected that the result is blurry since this setup prevents any smart handling of the transform by the Java paint code.

To fix this,

• I've made sure that the temporary image has size 800x600,
• set the transform of g in MapView.paint(Graphics g) to identity and
• set transform of the temporary image to the original transform of g.

[bastiK]

Last patch combines both fixes and should be ready for merging after the release (sans javadoc). Compiles with Java 8 and uses reflection to access the BaseMultiResolutionImage class.

[bastiK]

In 12722/josm:

see #9995 - fix blurry GUI-icons and map view for Java 9 HiDPI mode

[bastiK]

In 12723/josm:

see #9995 - fix double scaling with gui.scale Einstein option (change extracted from a patch by strump)

[bastiK]

Replying to anonymous:

Hi. I was out of Internet for some time and here's new patch:

1. stoecker, in commit 10428 you've modified ImageResource construcstor and inserted line:

    baseImage = scaleBaseImageIfNeeded(img);

This modification caused problems with overscaled images reported by Klumbumbus. I suppose that baseImage field holds original unmodified image as it's loaded from a file. And all dimension calulations are made based on this field. The fix is to use baseImage = img. This will solve problems with twice scaled icons.

Done.

2. SaveLayersDialog with three icons on a single button is fixed. I've created EmptyImageProvider class to generate empty (transparent) images. And also used addOverlay() method to combine three images in a row.

You forgot to add the EmptyImageProvider class to the patch!

3. When I've started HiDPI images refactoring I thought that all images allover JOSM will be scaled automatically. But there's place where image must be loaded from PNG and passed with no changes: app icons in MainFrame.initialize(). JOSM logo must be loaded and passed to setIconImages() as it is. So I've added method ImageProvider.getSourceImage() for that purpose.

I don't like the getSourceImage() method so much, see remarks in comment 75.

[bastiK]

The first series of patches by strump is still quite incomplete:

• The mapview area painting is inconsistent
• GUI elements, like table cells are not scaled, which cuts off the images inside

It is not an easy task to fix all the issues.

Now that the apparent problems with Java 9 HiDPI mode are fixed, I suggest to wait for some positive test results, then start to roll back the gui.scale code.

One oddity I found with Java 9 HiDPI: It seems to be impossible to get the pixel coordinates of the mouse cursor. Mouse coordinates are always divided by the scale factor and rounded to integer. So with GDK_SCALE=4, when the user moves the mouse by 3 pixels, it cannot be detected. As a result, you can only move a node by increments of 2/4/... pixels.
In practice it is hard notice, unless you know what to look for. So I think it is only a problem, if we make it one. Anyway, it could warrant a Java bug report.

[bastiK]

In 12724/josm:

see #9995 - fix headless mode

[Don-vip]

In 12732/josm:

see #9995 - sonar - squid:S3655 - Optional value should only be accessed after calling isPresent()

[Don-vip]

Ticket #11806 has been marked as a duplicate of this ticket.

[bastiK]

Possible TODO from #11806:

Comment by mjog:

[...]

4. Map custom cursors are not scaled and hence are tiny

[...]

Size of custom cursor should match the system cursor. On my system, this is the case, as the GDK_SCALE=2 environment variable does not affect the size of the system cursor. (Only the JOSM window is in HiDPI mode.)

HiDPI cursor scaling is something that Java should do correctly on its own (as long as the API is used as intended).

[bastiK]

In 12923/josm:

see #9995 - add advanced option to scale the menu font (gui.scale.menu.font)

[bastiK]

New wiki page with info: Help/HiDPISupport

Judging from the feedback on the German forum, the changes in [12722] seem to have the intended effect. As far as I can tell, JOSM should now be HiDPI-ready. Further improvements can be dealt with in separate tickets and linked here. One of those would be #15240 (transform gui icons to svg).

[Don-vip]

In 14342/josm:

see #9995, see #13173 - adjust symbol shapes size based on current DPI

[BrackoNe]

It seems that this issue is still present.
I'm using Microsoft Surface Book 2 (res. 3240 x 2160; scale 200%).
When I start the app (JOSM) everything seems to be working, until you click on any of the imageries. Once the imagery is chosen, everything goes mad and turns all icons to extremely small (as ian1caldwell reported).

Is there any solution 6 years after?

[skyper]

Replying to BrackoNe:

It seems that this issue is still present.
I'm using Microsoft Surface Book 2 (res. 3240 x 2160; scale 200%).
When I start the app (JOSM) everything seems to be working, until you click on any of the imageries. Once the imagery is chosen, everything goes mad and turns all icons to extremely small (as ian1caldwell reported).

Is there any solution 6 years after?

There have been quite some improvement, lately and there are still some open tickets: query

If you have problems, please, open a new ticket with all needed information using Report bug or comment on open tickets if one covers your problem instead of bringing up this fixed ticket after almost two years. Thanks.