Modify

Opened 4 years ago

Closed 2 months ago

#9995 closed defect (fixed)

[PATCH] Icons and fonts too small with HIDPI displays

Reported by: ian1caldwell@… Owned by: team
Priority: normal Milestone: 17.09
Component: Core Version: tested
Keywords: retina high dpi screen resolution windows 4k hidpi Cc: RicoElectrico

Description (last modified by Klumbumbus)

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:
screen shot at 1920x1080 resolution

3200x1800:
screen shot at 3200x1800 resolution

Attachments (16)

3200x1800.png (685.7 KB) - added by ian1caldwell@… 4 years ago.
screen shot at 3200x1800 resolution
1920x1080.png (465.5 KB) - added by anonymous 4 years ago.
screen shot at 1920x1080 resolution
hidpi_patch_1_images.patch (36.1 KB) - added by strump 18 months ago.
hidpi_patch_2_images_leftovers.patch (38.4 KB) - added by strump 18 months ago.
josm-scale=2.png (239.9 KB) - added by bastiK 18 months ago.
hidpi_patch_3_images_progress.patch (22.1 KB) - added by strump 18 months ago.
5_Note_default.png (2.9 KB) - added by strump 18 months ago.
5_Note_hidpi_buggy.png (6.5 KB) - added by strump 18 months ago.
5_Note_hidpi_fixed.png (6.5 KB) - added by strump 18 months ago.
guiscale2_edittoolbar.png (71.2 KB) - added by Klumbumbus 18 months ago.
taskbar_pixel.png (19.0 KB) - added by Klumbumbus 18 months ago.
3sizes.png (52.0 KB) - added by Klumbumbus 18 months ago.
patch_4_images_progress.patch (10.2 KB) - added by anonymous 18 months ago.
multi-resolution-images.patch (2.4 KB) - added by bastiK 4 months ago.
hidpi-mapview.patch (6.0 KB) - added by bastiK 4 months ago.
hidpi-support.patch (33.1 KB) - added by bastiK 3 months ago.

Download all attachments as: .zip

Change History (136)

comment:1 Changed 4 years ago by Don-vip

Owner: changed from team to ian1caldwell@…
Status: newneedinfo

Could you please attach a screenshot? Thanks.

Changed 4 years ago by ian1caldwell@…

Attachment: 3200x1800.png added

screen shot at 3200x1800 resolution

Changed 4 years ago by anonymous

Attachment: 1920x1080.png added

screen shot at 1920x1080 resolution

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by Don-vip

Description: modified (diff)
Owner: changed from ian1caldwell@… to team
Status: needinfonew

thanks.

comment:4 Changed 4 years ago by stoecker

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

comment:5 in reply to:  4 Changed 4 years ago by 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...

comment:6 Changed 4 years ago by Don-vip

Looks like High-DPI screens on Windows are not officialy supported by Java itself:
https://bugs.openjdk.java.net/browse/JDK-8029087

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

Version 0, edited 4 years ago by Don-vip (next)

comment:7 Changed 3 years ago by Don-vip

Keywords: retina high dpi screen resolution windows added

comment:8 Changed 3 years ago by Don-vip

See #10343 for another related problem.

comment:9 Changed 3 years ago by 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)

Last edited 3 years ago by Don-vip (previous) (diff)

comment:10 Changed 2 years ago by 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?

comment:11 Changed 2 years ago by 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.

comment:12 Changed 2 years ago by Don-vip

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

comment:13 Changed 2 years ago by 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/

comment:14 Changed 2 years ago by mdk

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

comment:15 Changed 2 years ago by 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.

comment:16 Changed 2 years ago by Don-vip

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

comment:17 Changed 23 months ago by stoecker

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

comment:18 Changed 23 months ago by stoecker

Summary: Icons too small on windows 8.1 with a 'retina' displayIcons and fonts too small with HIDPI displays

comment:19 Changed 21 months ago by 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.)

comment:20 Changed 20 months ago by Don-vip

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

comment:21 Changed 20 months ago by Klumbumbus

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

comment:22 Changed 20 months ago by Klumbumbus

Description: modified (diff)
Keywords: 4k hidpi added

comment:23 Changed 20 months ago by Klumbumbus

Description: modified (diff)

comment:24 Changed 19 months ago by Klumbumbus

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

comment:25 Changed 19 months ago by Don-vip

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

comment:26 Changed 18 months ago by 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:

https://dl.dropboxusercontent.com/u/16093742/bug/josm_hidpi_size_fix.png

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.

comment:27 Changed 18 months ago by 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.

comment:28 Changed 18 months ago by 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 :-)

comment:29 Changed 18 months ago by 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?
  1. 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?
  1. May I use your wiki to track my progress? I need to store my ideas and trace all places affected by UI scaling feature.

comment:30 in reply to:  29 Changed 18 months ago by 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.

  1. 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 :-)

  1. 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...

comment:31 Changed 18 months ago by 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?

comment:32 Changed 18 months ago by stoecker

Milestone: 16.06
Summary: Icons and fonts too small with HIDPI displays[PATCH] Icons and fonts too small with HIDPI displays
-            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.

comment:33 Changed 18 months ago by 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.

comment:34 Changed 18 months ago by stoecker

In 10356/josm:

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

comment:35 Changed 18 months ago by stoecker

Last changeset makes the SideButton changes obsolete. :-)

comment:36 Changed 18 months ago by stoecker

In 10357/josm:

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

comment:37 Changed 18 months ago by stoecker

In 10358/josm:

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

comment:38 Changed 18 months ago by stoecker

In 10359/josm:

see #9995 - overlooked part of the code

comment:39 Changed 18 months ago by 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.

comment:40 in reply to:  33 Changed 18 months ago by 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.

comment:41 in reply to:  39 ; Changed 18 months ago by 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?

comment:42 in reply to:  41 Changed 18 months ago by 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.

Changed 18 months ago by strump

Attachment: hidpi_patch_1_images.patch added

Changed 18 months ago by strump

comment:43 Changed 18 months ago by 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 :)

comment:44 Changed 18 months ago by stoecker

In 10369/josm:

see #9995 - patch by strump - improve HIDPI

comment:45 Changed 18 months ago by 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...

comment:46 Changed 18 months ago by 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.

comment:47 Changed 18 months ago by stoecker

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

comment:48 in reply to:  45 Changed 18 months ago by 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() ?

comment:49 Changed 18 months ago by 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.

comment:50 Changed 18 months ago by 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

Changed 18 months ago by bastiK

Attachment: josm-scale=2.png added

comment:51 Changed 18 months ago by 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.

Changed 18 months ago by strump

Changed 18 months ago by strump

Attachment: 5_Note_default.png added

Changed 18 months ago by strump

Attachment: 5_Note_hidpi_buggy.png added

Changed 18 months ago by strump

Attachment: 5_Note_hidpi_fixed.png added

comment:52 Changed 18 months ago by 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.

Last edited 18 months ago by strump (previous) (diff)

comment:53 Changed 18 months ago by 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.

comment:54 in reply to:  51 Changed 18 months ago by 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.

comment:55 Changed 18 months ago by stoecker

In 10428/josm:

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

comment:56 Changed 18 months ago by stoecker

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

comment:57 Changed 18 months ago by 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.

comment:58 Changed 18 months ago by Don-vip

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

comment:59 Changed 18 months ago by Don-vip

Cc: RicoElectrico added

comment:60 Changed 18 months ago by stoecker

In 10484/josm:

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

comment:61 Changed 18 months ago by 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.

comment:62 in reply to:  61 Changed 18 months ago by 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.

comment:63 Changed 18 months ago by 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?

comment:64 Changed 18 months ago by 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

comment:65 Changed 18 months ago by 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?

comment:66 Changed 18 months ago by bastiK

Priority: normalblocker

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.

comment:67 in reply to:  66 Changed 18 months ago by 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.

comment:68 in reply to:  65 Changed 18 months ago by 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.

comment:69 Changed 18 months ago by 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)
Last edited 18 months ago by Klumbumbus (previous) (diff)

Changed 18 months ago by Klumbumbus

Attachment: guiscale2_edittoolbar.png added

Changed 18 months ago by Klumbumbus

Attachment: taskbar_pixel.png added

comment:70 Changed 18 months ago by Klumbumbus

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


Changed 18 months ago by Klumbumbus

Attachment: 3sizes.png added

comment:71 Changed 18 months ago by bastiK

In 10505/josm:

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

comment:72 Changed 18 months ago by bastiK

Priority: blockernormal

comment:73 Changed 18 months ago by Don-vip

Milestone: 16.0616.07

Changed 18 months ago by anonymous

comment:74 Changed 18 months ago by 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.

  1. 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.
  1. 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

comment:75 Changed 17 months ago by 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.

comment:76 in reply to:  75 Changed 17 months ago by 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.

comment:77 in reply to:  74 Changed 17 months ago by 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.

comment:78 Changed 17 months ago by 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

comment:79 Changed 17 months ago by 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.

comment:80 Changed 16 months ago by Don-vip

Milestone: 16.0716.08

comment:81 Changed 16 months ago by stoecker

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

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

comment:82 Changed 16 months ago by Don-vip

Milestone: 16.0816.09

comment:83 Changed 15 months ago by anonymous

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

comment:84 Changed 15 months ago by Don-vip

Milestone: 16.0916.10

comment:85 Changed 14 months ago by simon04

Milestone: 16.1016.11

Milestone renamed

comment:86 Changed 14 months ago by 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

comment:87 Changed 12 months ago by Don-vip

Milestone: 16.1116.12

Milestone renamed

comment:88 Changed 12 months ago by 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.

comment:89 Changed 11 months ago by Don-vip

Milestone: 16.1217.01

comment:90 Changed 11 months ago by 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)
Last edited 11 months ago by solitone (previous) (diff)

comment:91 Changed 11 months ago by Don-vip

Milestone: 17.0117.02

comment:92 in reply to:  90 Changed 10 months ago by Don-vip

Replying to solitone:

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

this has been solved through #14211

comment:93 Changed 10 months ago by Don-vip

Milestone: 17.0217.03

comment:94 Changed 9 months ago by Don-vip

Milestone: 17.03

comment:95 Changed 8 months ago by Don-vip

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

comment:96 Changed 4 months ago by bastiK

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

comment:97 Changed 4 months ago by 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.

comment:98 Changed 4 months ago by 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.

Changed 4 months ago by bastiK

comment:99 Changed 4 months ago by 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).

comment:100 in reply to:  99 Changed 4 months ago by 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.

comment:101 Changed 4 months ago by 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.

comment:102 Changed 4 months ago by 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.

Last edited 4 months ago by Don-vip (previous) (diff)

comment:103 Changed 4 months ago by 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.

comment:104 Changed 4 months ago by Klumbumbus

A bit Java 9 HDPI feedback in german forum

comment:105 Changed 4 months ago by Don-vip

is it good or bad? :)

comment:106 Changed 4 months ago by Klumbumbus

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

comment:107 Changed 4 months ago by 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.

Changed 4 months ago by bastiK

Attachment: hidpi-mapview.patch added

comment:108 Changed 4 months ago by 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.

Changed 3 months ago by bastiK

Attachment: hidpi-support.patch added

comment:109 Changed 3 months ago by bastiK

Milestone: 17.09

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.

comment:110 Changed 3 months ago by bastiK

In 12722/josm:

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

comment:111 Changed 3 months ago by bastiK

In 12723/josm:

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

comment:112 in reply to:  74 Changed 3 months ago by 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.

  1. 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!

  1. 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.

comment:113 Changed 3 months ago by 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.

comment:114 Changed 3 months ago by bastiK

In 12724/josm:

see #9995 - fix headless mode

comment:115 Changed 3 months ago by Don-vip

In 12732/josm:

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

comment:116 Changed 3 months ago by Don-vip

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

comment:117 Changed 3 months ago by bastiK

Possible TODO from #11806:

Comment by mjog:

[...]

  1. 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).

comment:118 Changed 2 months ago by Don-vip

Milestone: 17.0917.10

comment:119 Changed 2 months ago by bastiK

In 12923/josm:

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

comment:120 Changed 2 months ago by bastiK

Milestone: 17.1017.09
Resolution: fixed
Status: newclosed

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).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.