Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapview scaling issue on Windows when not using 100% display scaling #81

Closed
vewert opened this issue Apr 17, 2020 · 12 comments
Closed

Mapview scaling issue on Windows when not using 100% display scaling #81

vewert opened this issue Apr 17, 2020 · 12 comments

Comments

@vewert
Copy link

@vewert vewert commented Apr 17, 2020

I was testing my application on various computers and found a strange issue. Inside the mapview, the map image was only partially filling the view, but markers were behaving as if the map filled the whole view; causing strange behavior when the map is panned and zoomed. It turns out, that the computer (Windows 10) I was using, was set to have its display scale set to 125%. If I switched it to 100%, the problem went away.

I was able to reproduce this problem, using your example app and have attached a screen shot:

mapjfx-screenshot

I did some investigation and found there is jvm arg, that controls allowing hidpi; setting it to false seems to fix the problem (-Dprism.allowhidpi=false). This seems like usable work-around, but it effectively turns off hidpi for the entire application, which may not be ideal.

I did some further investigation and found the following bug against jdk/javafx: https://bugs.openjdk.java.net/browse/JDK-8234471

This looks similar, but I'm not sure if you are using a canvas tag or not.

I don't know if this is something you can fix or not, but thought I should log it for your reference and/or in case anyone else ran into this issue. Let me know if you need any further information.

Thanks again for developing such a great mapping utility.

@sothawo
Copy link
Owner

@sothawo sothawo commented Apr 19, 2020

This is probably the same as #36 and the same problem described in https://www.sothawo.com/2018/02/mapjfx-problems/#comment-999.

I put this in a new post: https://www.sothawo.com/2020/04/mapjfx-display-problems-update/, but I'm afraid that without high resolution hardware I cannot investigate further into this

@Abu-Abdullah
Copy link

@Abu-Abdullah Abu-Abdullah commented Sep 1, 2020

i can confirm this as well. and the workaround works as well.

the good news, the bug highlited by @vewert is solved in jfx 16-ea+1 version and it works fine now without any issue

@Abu-Abdullah
Copy link

@Abu-Abdullah Abu-Abdullah commented Sep 1, 2020

it might be good to raise the dependency to this version as it is compatible with LTS 11.

this is a core issue in Windows and my laptop is very old and does not seem to have anything special about the screen, hence im expecting most people using windows will suffer this. so i would recommend to raise the dependecy to 16-ea+1 even though it is a beta version.

@sothawo
Copy link
Owner

@sothawo sothawo commented Sep 2, 2020

thanks for this information; I don't think I'll update to 16 yet but stay on 11 LTS with master until the next LTS is out. I will check if I will get out a new branch/version for 16

@Abu-Abdullah
Copy link

@Abu-Abdullah Abu-Abdullah commented Sep 2, 2020

it seems i didn't put it correctly. i meant to raise the dependecy of jfx to 16 not the jdk. jfx 16 is compatible with LTS jdk 11

@vewert
Copy link
Author

@vewert vewert commented Sep 2, 2020

@Abu-Abdullah, thanks for the update, I'm just wondering, did you try JavaFX15 to see if that resolves the issue as well? According to the bug JDK-8234471, it looks like it might have been fixed in 15.

@sothawo
Copy link
Owner

@sothawo sothawo commented Sep 2, 2020

sure. But if I raise the dependency to javafx16 that means that everyone using mapjfx will have jfx16 even on system where this is no issue.

@sothawo
Copy link
Owner

@sothawo sothawo commented Sep 2, 2020

I just tried this on a virtual machine and could reproduce it with jfx11. The problem did not appear with 15-ea+8 or 16-ea-1.
So JDK-8234471 seems to have fixed this.
No need to update mapjfx from jfx11, all you need is add the corresponding dependency to javafx-web in the application using mapjfx. I'll write a short post about this.

@sothawo
Copy link
Owner

@sothawo sothawo commented Sep 2, 2020

can you please try to use the updated dependency (https://www.sothawo.com/2020/09/mapjfx-display-problem-on-windows-10-seems-solved/) and check if this solves the problem?

@vewert
Copy link
Author

@vewert vewert commented Sep 2, 2020

I did a quick test of my application, using jfx 15-ea+8, and indeed the problem looks to be solved! (Note: was still using jdk 11 for my test).

As a side note, I set the JavaFX dependency using Gradle and the javafx-gradle-plugin as follows:

javafx {
  version = "15-ea+8"
  modules("javafx.controls", "javafx.fxml", "javafx.media", "javafx.graphics", "javafx.web")
}

@Abu-Abdullah
Copy link

@Abu-Abdullah Abu-Abdullah commented Sep 3, 2020

yes it works with jfx 15 for me as well. i guess we can have different dependency version for windows e.g.

<dependency>
	<groupId>org.openjfx</groupId>
	<artifactId>javafx-web</artifactId>
	<version>15-ea+8</version>
	<classifier>win</classifier>
</dependency>

thank you for the quick updates on this library

@sothawo
Copy link
Owner

@sothawo sothawo commented Sep 3, 2020

well, there is no update necessary.
If I would add the dependency on version 15 in the mapjfx pom, I would force this version onto every (windows) user that's using it. The problem does not happen everywhere, it depends on the display setting. mapjfx is a library that is used by applications, and the applications should define the version of JavaFX to use. If you put this dependency in your application it will override the version that is defined in mapjfx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants