You are not logged in.
Jun 03, 2023 1:22:27 AM com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
WARNING: Exception while evaluating select-binding
Buggy Java code.
And the segfaults happen in the bundled libjvm.so, might be ABI incomatible with post 2012 glibc's …
(Writing in java to then rely on a bundled VM is beyond idiotic…)
But, apparently one instrument is having the fonts bigger than it should be, not showing properly.
Most likely unrelated and down to a missing font, but hard to tell w/o specifics.
Online
Jun 03, 2023 1:22:27 AM com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue WARNING: Exception while evaluating select-binding
Buggy Java code.
And the segfaults happen in the bundled libjvm.so, might be ABI incomatible with post 2012 glibc's …
I was reading a post on reddit about the glibc, apparently, if I understood well, there's no good fix for this kind of issue other than install a Debian with an older version of glibc.
(Writing in java to then rely on a bundled VM is beyond idiotic…)
Haha, yeah, I believe they must be a small team of devs, but the program does what the competitors don't, specially for the price.
felipescotti wrote:But, apparently one instrument is having the fonts bigger than it should be, not showing properly.
Most likely unrelated and down to a missing font, but hard to tell w/o specifics.
I tried to install some fonts that I acknowledge on the instrument code, but no success with that. But I'm mostly getting it working changing some values on the instrument code to adjust position and size.
Either I can install Debian to do a test or buy the version 4 of the software.
Thanks for the help I got from you all!
Last edited by felipescotti (2023-06-06 00:27:16)
Offline
there's no good fix for this kind of issue other than install a Debian with an older version of glibc
You could try to replace the bundled JRE w/ one from the repos.
I'd suggest to run the software with a sufficiently dated distro in a virtual machine.
but the program does what the competitors don't, specially for the price.
I was about to snap back w/ "updates", but apparently there's one
I tried to install some fonts that I acknowledge on the instrument code
Do you have comperative screenshots?
Online
You could try to replace the bundled JRE w/ one from the repos.
I'd suggest to run the software with a sufficiently dated distro in a virtual machine.
I would like to try to replace the JRE, but I need to find out how as I have no idea.
Would I have to replace only the jre folder or also databases and libs?
I have the impression that running on a VM would bring even more issues as this software needs to run connected with the simulator.
I was about to snap back w/ "updates", but apparently there's one
Yes, but now I can confirm that the issue with fonts happens also on Debian running AirManager 4.x as
I'm trying to check it with the Instrument author and also on AirManager's forum.
Very tricky bug I guess haha
Do you have comperative screenshots?
Screenshots from the instrument or AirManager?
The fonts I installed didn't make any difference, I found out that the instrument uses its own fonts, they are inside "/home/user/AirManager/instruments/"instrument folder"/resources"
Some can be checked on page 2 of comments here:
https://forums.x-plane.org/index.php?/f … ent-383043
and
https://siminnovations.com/forums/viewtopic.php?t=7809
Thanks!
Last edited by felipescotti (2023-06-09 03:57:36)
Offline
xdpyinfo | grep resolution
xrandr -q
xrdb -q | grep -i dpi
Online
xdpyinfo | grep resolution xrandr -q xrdb -q | grep -i dpi
Initially I thought that the instrument issue could be in fact the "window loading small instead of the font too big", I tried to change the screen resolution and I can also select on AirManager which screen I want to open the instrument, change its size, resolution, aspect ration, scale but the results are always the same independent of these settings, I only got better results changing instrument code values.
The AirManager team also confirm that "the instruments code are the same across platforms and rendering is done in openGL directly, so there is no real dependency on scaling, display, etc so". As the instrument got the same issue when loaded on Air Manager 4.x and Debian Linux (supported), but load perfectly when loaded on any version of Air Manager for Windows, I can only conclude that the issue is on (Air Manager Linux version) side. What is weird though is that all the others instruments load normally on AM Linux, cheeky issue, haha.
I just searched repos for OpenGL and found a lot of stuff related on Extra and Multilib, wondering if any of that could solve the issue.
Any case, here is the result for the commands you asked:
(Last command didn't return anything).
[felipe@FS-PC ~]$ xdpyinfo | grep resolution
resolution: 60x60 dots per inch
[felipe@FS-PC ~]$ xrandr -q
Screen 0: minimum 8 x 8, current 4209 x 1848, maximum 32767 x 32767
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 1920x1080+2289+0 (normal left inverted right x axis y axis) 1600mm x 900mm
3840x2160 30.00 + 59.94 50.00 29.97 25.00 23.98
4096x2160 59.94 50.00 29.97 25.00 24.00 23.98
1920x1080 119.88* 100.00 60.00 59.94 50.00 29.97 25.00 23.98
1360x768 60.02
1280x1024 60.02
1280x720 59.94 50.00
1152x864 60.00
1024x768 60.00
800x600 60.32
720x576 50.00
720x480 59.94
640x480 59.95 59.94 59.93
HDMI-0 connected 1024x768+3185+1080 (normal left inverted right x axis y axis) 256mm x 192mm
1024x768 60.00*+
1920x1080 60.00 59.94
1440x900 59.89
1360x768 60.02
1280x1024 60.02
1280x960 60.00
1280x800 59.81
1280x720 59.94
720x480 59.94 59.94
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected primary 1920x1080+369+0 (normal left inverted right x axis y axis) 1600mm x 900mm
3840x2160 30.00 + 59.94 50.00 29.97 25.00 23.98
4096x2160 59.94 50.00 29.97 25.00 24.00 23.98
1920x1080 119.88* 100.00 60.00 59.94 50.00 29.97 25.00 23.98
1360x768 60.02
1280x1024 60.02
1280x720 59.94 50.00
1152x864 60.00
1024x768 60.00
800x600 60.32
720x576 50.00
720x480 59.94
640x480 59.95 59.94 59.93
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1366x768+1366+1080 (normal left inverted right x axis y axis) 340mm x 190mm
1366x768 59.79*+
1920x1080 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1280x800 59.91
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 66.01 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 connected 1366x768+0+1080 (normal left inverted right x axis y axis) 340mm x 190mm
1366x768 59.79*+
1920x1080 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1280x800 59.91
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 66.01 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
1920x1080 (0x1cc) 148.500MHz +HSync +VSync
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz
v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz
1920x1080 (0x1ce) 148.500MHz +HSync +VSync
h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz
v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz
1280x720 (0x1d5) 74.250MHz +HSync +VSync
h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.50KHz
v: height 720 start 725 end 730 total 750 clock 50.00Hz
1024x768 (0x1d7) 65.000MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz
v: height 768 start 771 end 777 total 806 clock 60.00Hz
800x600 (0x1d8) 40.000MHz +HSync +VSync
h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz
v: height 600 start 601 end 605 total 628 clock 60.32Hz
720x576 (0x1d9) 27.000MHz -HSync -VSync
h: width 720 start 732 end 796 total 864 skew 0 clock 31.25KHz
v: height 576 start 581 end 586 total 625 clock 50.00Hz
720x480 (0x1da) 27.000MHz -HSync -VSync
h: width 720 start 736 end 798 total 858 skew 0 clock 31.47KHz
v: height 480 start 489 end 495 total 525 clock 59.94Hz
640x480 (0x1dc) 25.175MHz -HSync -VSync
h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz
v: height 480 start 490 end 492 total 525 clock 59.94Hz
[felipe@FS-PC ~]$ xrdb -q | grep -i dpi
[felipe@FS-PC ~]$ xrdb -q | grep -i dpi
[felipe@FS-PC ~]$ sudo pacman -S xorg-xrdb
[sudo] password for felipe:
warning: xorg-xrdb-1.2.2-1 is up to date -- reinstalling
Last edited by felipescotti (2023-06-10 02:33:28)
Offline
The AirManager team also confirm that "the instruments code are the same across platforms and rendering is done in openGL directly, so there is no real dependency on scaling, display, etc so".
seth confirms that the dpi will have a very real impact on xft and freetype.
resolution: 60x60 dots per inch
xrandr --dpi 96
before you launch the airmanager process.
You're running DP-1 and DP-3 at ~30dpi and HDMI-0, HDMI1 and HDMI3 at ~102dpi ??
Online
seth confirms that the dpi will have a very real impact on xft and freetype.
Hehehe
Even considering that apparently everything on Air Manager is bundled?
Checking the Air Manager settings, for Graphics API, I can select OpenGL2.0 or Automatic. Arch Linux is running a OpenGL version 4.6.
Is that means that the OpenGL 2.0 that Air Manager run is also Bundled??
Or maybe there is a incompatibility between both, in case it use partially 2.0 and partially 4.6 ?
Wondering if this could possibly be a direction:
https://docs.mesa3d.org/envvars.html
xrandr --dpi 96
before you launch the airmanager process.
Tried, nothing changed. Should I specify the monitor to run on this dpi?
You're running DP-1 and DP-3 at ~30dpi and HDMI-0, HDMI1 and HDMI3 at ~102dpi ??
How do I check that?
There are 3 TV's 4K 40" (but actually using 2) plugged in the RTX2080 Super and running at 1920x1080 120HZ
1 (5" screen) running at 1024x768 (could be 800x600) also plugged in the RTX (I run the defective instrument here, but tried in all other monitors)
2 touch screen 15.6" running at 1366x768 plugged in the MOBO (where I run most of the Air Manager instruments).
Nvidia settings creates a huge X Screen 0 and fit all screens inside it, but doesn't manage the 2 touch monitors.
X Screen 0:
4209x1848 pixels
96x96 dots per inch
depth: 24
Last edited by felipescotti (2023-06-10 09:10:28)
Offline
Even considering that apparently everything on Air Manager is bundled?
Yes or no. It doesn't matter that it's bundled but whether and which resolution parameters it interprets.
Arch Linux is running a OpenGL version 4.6.
No, your GPU/driver supports that level. AirManager only uses GL 2.0, but that doesn't matter.
Tried, nothing changed. Should I specify the monitor to run on this dpi?
No.
How do I check that?
Not. Your xrandr output already told that.
Can you run DP-1 and DP-3 at 3840x2160 (or just detach them) and see whether that has any impact on the font rendering behavior of AirManager?
Online
Yes or no. It doesn't matter that it's bundled but whether and which resolution parameters it interprets.
No, your GPU/driver supports that level. AirManager only uses GL 2.0, but that doesn't matter.
Got it!
Can you run DP-1 and DP-3 at 3840x2160 (or just detach them) and see whether that has any impact on the font rendering behavior of AirManager?
Yes, also tried to run using root account, all monitors on native resolution, restarted, tried again, nothing changed.
Worth to say, the instrument developer is running Debian on VMware and he also got the same result.
Last edited by felipescotti (2023-06-11 01:20:53)
Offline
Tell him to develop a smaller font in there?
Does he set the font size in points or pixels?
If points, try to play with
xrdb -m <<< "Xft.dpi: 72" # try different values, you're at 30 or 100, 72 and 96 are kinda "standards", smaller values would lead to smaller fonts
Otherwise the pixel value is too high, either because of a miscalculation or because of https://wiki.archlinux.org/title/HiDPI# … plications
Online
Tell him to develop a smaller font in there?
Does he set the font size in points or pixels?
I could ask him, is there a way I could check that by myself?
If points, try to play with
xrdb -m <<< "Xft.dpi: 72" # try different values, you're at 30 or 100, 72 and 96 are kinda "standards", smaller values would lead to smaller fonts
Otherwise the pixel value is too high, either because of a miscalculation or because of https://wiki.archlinux.org/title/HiDPI# … plications
Tried, only changes the KDE font size, mainly noticed on Dolphin.
I was thinking that maybe there is a difference on settings/features between Linux and Windows on the OpenGL or whatever is responsible to show the virtual display (in this case, the instrument) regarded to that specific font and was not settled properly to work equally on both OS. I also have the impression that the instrument's author years ago, modified the Fonts and probably didn't checked the results on Linux.
I almost found a solution. I noticed that the MCDU is the only one of the instruments that I use which has its own fonts inside the instrument "folder/resources", then I replaced them one by one with "digital-7-mono" just to make it easy to find out which one is being used for the display. Once I found out that "oxygenmono-regular.ttf" was the cheeky ones...
I downloaded it from here:
https://fonts.google.com/?query=oxygen+mono
and replace it.
Fitted almost perfectly, apart for some details which I believe can be easily fixed like replacing 2 characters and adjust its position on the instrument code.
Last edited by felipescotti (2023-06-12 10:34:02)
Offline
is there a way I could check that by myself?
Is the source open?
I downloaded it from here:
https://fonts.google.com/?query=oxygen+mono
and replace it.
If the cause is merely a bogus font, you can probably replace that w/ any kind of monospace font.
Online
Is the source open?
I don't think so, but it use open-source libraries.
If the cause is merely a bogus font, you can probably replace that w/ any kind of monospace font.
Yeah I played a bit using "digital-7-mono" hehe
Fixed everything basically Replacing the font, settled fixed values for the font size on the instrument code and readjusting position values and virtual screen width.
Tried to repeat with the original font, but then, didn't manage to align everything on the virtual screen.
Don't know if make sense but sounds for me like the font that was in use is too old and whatever is responsible to show it on the virtual screen is expecting the new version of this font.
Also, at least on the instrument code, fonts are settled in px:
font_SZ1 = "size:21px"..L_HXS.."px; font:mcdu_bold_sml.ttf; color:"
Not sure if this is also on AM code, but maybe this answer your previous question about pixels or points?
Last edited by felipescotti (2023-06-12 10:48:22)
Offline
Tell him to develop a smaller font in there?
Does he set the font size in points or pixels?
If points, try to play withxrdb -m <<< "Xft.dpi: 72" # try different values, you're at 30 or 100, 72 and 96 are kinda "standards", smaller values would lead to smaller fonts
Otherwise the pixel value is too high, either because of a miscalculation or because of https://wiki.archlinux.org/title/HiDPI# … plications
I kinda missed this, so much time on the pc that I have no conscious anymore, just my body here hahaha.
But actually this makes a lot of sense, I'm gonna also try this using the bogus font later.
Thank you for that!
Last edited by felipescotti (2023-06-12 10:44:31)
Offline
Not sure if this is also on AM code, but maybe this answer your previous question about pixels or points?
It would be pixels and if the issue is exclusively w/ the font too wide but NOT too high it's also less likely a metric issue and more a bogus assumption about the glyph width (and why a narrower font might work)
Online
It would be pixels and if the issue is exclusively w/ the font too wide but NOT too high it's also less likely a metric issue and more a bogus assumption about the glyph width (and why a narrower font might work)
It means that the "HiDPI#Java_applications" has more or less chances to work?:
I tried, but don't know exactly how to use it.
I tried to add once at a time :
-Dglass.gtk.uiScale=200%
and
-Dsun.java2d.uiScale=300%
(also tried different % values)
...to the file "info.xml" like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<application>
<name>Air Manager 3.7 (Home Use)</name>
<deployMode>UNZIP</deployMode>
<startupPath>./jre/bin/java -Dglass.gtk.uiScale=200% -Xmx512m -Xms128m -jar AirManager.jar</startupPath>
<platform>LINUX</platform>
<applicationGroup>AIR_MANAGER</applicationGroup>
<programCompilation>HOME_USE</programCompilation>
<major>3</major>
<minor>7</minor>
<build>4</build>
<beta>false</beta>
<releaseNotes>Hotfix 3.7.4:
</application>
Also tried to call through the terminal:
[felipe@FS-PC AM3x]$ ./jre/bin/java -Xmx512m -Xms128 -Dsun.java2d.uiScale=300% -jar AirManager.jar
And add to "AirManager.sh":
#!/bin/bash
./jre/bin/java -Xmx512m -Xms128 -Dsun.java2d.uiScale=300% -jar AirManager.jar
cd "$(dirname "$0")"
./Bootloader
Nothing changed.
Last edited by felipescotti (2023-06-13 02:45:09)
Offline
"less to none"
Either the font reports or the code assumes a wrong glyph width.
The developer should know about the latter and if you can't figure the former (eg. w/ fontforge) you'd need to share the font file somehow (ask the developer about the legal situation of that so he won't be pissed if he finds this thread )
Online
"less to none"
Either the font reports or the code assumes a wrong glyph width.
The developer should know about the latter and if you can't figure the former (eg. w/ fontforge) you'd need to share the font file somehow (ask the developer about the legal situation of that so he won't be pissed if he finds this thread )
So... the instrument maintainer tried, but gave up due to time consuming and he don't wanna try to make code adjustments because the issue also happens when running a simple instrument created for testing purposes using the new oxygen font, indicating an issue with Air Manager for Linux. It's on the Air Manager's Devs hands now.
However, I checked the AM folder installation and didn't find the the oxygen font, also checked on their website to confirm:
https://siminnovations.com/wiki/index.p … uded_fonts
As I never tried to create an instrument myself using AM yet, I have no idea if the A.M has "obligation" to support a non included font.
I believe that it could means that the instrument maintainer would have to replace the font with one of the listed ones and readjust the code for that.
When I reported the issue to him I thought I was helping to make the instrument better, but in my understanding it was created and maintained by an Impassioned for Simulation on his free time and available for free to everyone and because he mentioned it has been too time consuming to try fixing it, I prefer to respect his decision and not to keep reporting there.
Regarding to share the font, it's on the instrument and not AM, than there would be no legal issue I guess. But I checked on FontForge and apparently both the original and the ones I downloaded has the same width '1229'.
The most important is that the font issue is not related to the Air Manager's Java error logs I'm getting every time I run it, but since I fixed it on the code myself and I see no issues when running (apart from the error log), it's fine. Though would be nice trying replace the Java with the one from repos just by curiosity.
Thanks!!
Last edited by felipescotti (2023-06-18 00:06:38)
Offline