RPTools
[Bug]: LibGDX rendering of map doesn't work correctly on mac os
Describe the Bug
Clicking on the LibGDX button to enable the LibGDX renderer offsets the map and renders it incorrecly under Mac OS
Standard Renderer
LibGDX
You will notice the selection border around the selected token is also in the wrong spot.
The map is only displayed in the bottom left corner of the screen, as shown, regardless of scrolling or zooming.
The layer selection box in top right hand corner is rendered briefly while interacting with tokens, scrolling, or zooming but quickly disappears agaon
To Reproduce
Run on Mac OS and click on the LibGX button
Expected Behaviour
Positions of map, selection, should remain the same and the layer selection should not dissapear
Screenshots
No response
MapTool Info
Develop
Desktop
Mac OS
Additional Context
No response
@thelsing This is due to the backend being used. It's a problem with JOGL and HiDPI (Retina) macs (so every mac made in the last 9 years). JOGL was deprecated as a backend for LibGDX over 12 years ago, so we need to swap the backend to LWJGL
FYI @kwvanderlinde
lwjgl had some issues on macos when I started with libgdx. The jogl backend was removed back then, because lwjgl could do everything jogl could do, until macos changed. But in the meantime they fixes it. Last time I checked the jogl had a better performance when embedded in swing. My only macos device that I have access to is a mac mini via vnc so I never tested HDPI.
There is probably a way set the scaling on GlJPanel. But if lwjgl2 already does this switching may be better.
lwjgl had some issues on macos when I started with libgdx. The jogl backend was removed back then, because lwjgl could do everything jogl could do, until macos changed. But in the meantime they fixes it. Last time I checked the jogl had a better performance when embedded in swing. My only macos device that I have access to is a mac mini via vnc so I never tested HDPI.
There is probably a way set the scaling on GlJPanel. But if lwjgl2 already does this switching may be better.
Every discussion I found said it can't be fixed under JOGL for mac os x, I tend to believe this as you don't know what scaling level the user has set for their display.
So I guess it needs to be migrated to the lwjgl back end (which I think they use version 3 now). And as far as performance goes hopefully it isn't less performant than JOGL as the JOGL back end is so bad on Mac OS its not funny, its about 6 times slower than the current java graphics 2d map renderer.
If someone with access to a mac wants to fix it in the jogl backend I guess one has to fix this line. Maybe with something like this
If someone with access to a mac wants to fix it in the jogl backend I guess one has to fix this line.
The scaling factor can't be constant because the user can change it
Regardless even if we could fix it in JOGL easily, we can't run with something that has been deprecated and removed for over a decade as one day suddenly due to OS upgrades or java upgrades the renderer could stop working and there will be no fix from the libgdx team
Regardless of backend, there's a number of issues that crop up in the GdxRenderer itself when UI scaling is in play. I've poked at fixing it, but I'll let the current round of PRs settle before pushing anything there.
I think #5478 has the same cause, but we'll have to see once it can get tested on MacOS specifically.
Regardless of backend, there's a number of issues that crop up in the GdxRenderer itself when UI scaling is in play. I've poked at fixing it, but I'll let the current round of PRs settle before pushing anything there.
I think #5478 has the same cause, but we'll have to see once it can get tested on MacOS specifically.
Oh it still may be a problem in LWJGL, but given JOGL was explicently deprecated and removed so long ago there is no use trying to fix the problem with JOGL as we need to move to LWJGL