MacOS surface-scale fix#35
Merged
wcmatthysen merged 2 commits intoWorldWindEarth:developfrom May 22, 2019
wcmatthysen:macos-pixel-scale-fix
Merged
MacOS surface-scale fix#35wcmatthysen merged 2 commits intoWorldWindEarth:developfrom wcmatthysen:macos-pixel-scale-fix
wcmatthysen merged 2 commits intoWorldWindEarth:developfrom
wcmatthysen:macos-pixel-scale-fix
Conversation
According to @pcmehlitz, if we update to the latest version of JOGL and we do not explicitly set the surface-scale factor to 1.0 in the different constructors of WorldWindowGLCanvas, we will end up with a surface-scale factor of 2.0 on MacOS machines with high-DPI displays. To quote his original commit-message: "there is one more serious issue that manifests at least on OX X machines with high DPI (e.g. Macbook Pros with retina display). If we do not explicitly request pixel scale factors of 1.0 in the worldwind.awt.WorldWindowGLCanvas, we end up with factors of 2.0 after the GLCanvas is realized, which then causes all AWTInputHandler mouse callbacks to receive MouseEvents with wrong coordinates (0.5 of what they should be), which in turn causes operations that compute world coordinates from screen coordinates to fail (e.g. click-to-re-center)." See: pcmehlitz@3c8322d
Moved the set-surface-scale logic out of the constructors into a separate method called initializeSurfaceScale(). We call this method from the different constructors.
Member
Author
|
@emxsys, I think we can merge this as it is a default step that should have been taken originally to get the scale-factor right on Macs. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of the Change
According to @pcmehlitz, if we update to the latest version of JOGL and we do not explicitly set the surface-scale factor to 1.0 in the different constructors of WorldWindowGLCanvas, we will end up with a
surface-scale factor of 2.0 on MacOS machines with high-DPI displays. To quote his original commit-message:
"there is one more serious issue that manifests at least on OX X machines with high DPI (e.g. Macbook Pros with retina display). If we do not explicitly request pixel scale factors of 1.0 in the worldwind.awt.WorldWindowGLCanvas, we end up with factors of 2.0 after the GLCanvas is realized, which then causes all AWTInputHandler mouse callbacks to receive MouseEvents with wrong coordinates (0.5 of what they should be), which in turn causes operations that compute world coordinates from screen coordinates to fail (e.g. click-to-re-center)."
See: pcmehlitz@3c8322d
Unfortunately I do not own a Mac, so I can't test this on my side. Can we get this tested by someone else to confirm that it works.
Why Should This Be In Core?
Critical bug-fix for MacOS users.
Benefits
Improving the stability of the code-base.
Potential Drawbacks
None
Applicable Issues
None