Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4

[DerReisende77]

@beta-tester
GDK_SCALE=2 java -Xmx1G -Djdk.gtk.version=3 -jar…

Libgtk3 muss dafür installiert sein und sollte die kleinen Komponenten lesbar hoch skalieren.

[beta-tester]

@DerReisende77
Danke für den tipp mit dem scale, aber das bläst nur die Gtk elemente auf das dopperlte auf, aber die schriften die vorher unlesbar klein gewesen waren, sind immer noch genauso winzig wie ohne dem scale…

EDIT: gibt es einen scale parameter nur für javaJFX ?

[beta-tester]

@DerReisende77
interessant, wenn ich meinen RPi4 auf eine auflösung von 4k (3840x2160 native auflösung des TV) einstelle, und dann MediathekView öffne, dann sind die kleinen schriften zwar immer noch klein, aber dafür gestochen scharf und leserlich…
jedoch auf die entfernung vom sessel aus ist diese auflösung nicht mehr lesbar.
komisch, dass diese schriften scheinbar optisch konstant groß bleiben.
sind diese schriften auf eine bestimmte mm-größe (MilliMeter) eingestellt, statt sich der übrigen skalierung unterzuordnen wie es GTK_SCALE für die anderen elemente tut?

EDIT: wenn ich, während MediathekView noch ausgeführt wird, die auflösung (quasi unterm hintern weg) von 3849x2160 zurück auf 1920x1080 stelle, ist alles wie es ein sollte.
die winzigen schriften sind größer und immer noch scharf/gut lesbar

jedoch MV einmal schließen und dann neu öffnen und alles ist wieder unleserlich verschwommen klein

PS.: ich meine die schriften/elemente im filterdialog, dem filtereingabefeld, der unteren statusleiste, …
nicht die anderen schriften wie der filmliste!
ich schreibe das nur, damit nicht jemand meint, ich wäre schwer sehbehindert

[Ein ehemaliger Benutzer]

@beta-tester sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

ich habe jetzt mal die bellsoft-jdk11.0.6+10-linux-arm32-vfp-hflt-full.deb installiert und deine MediathekView_linux-arm32_11.0.6.jar ausgeführt.
es kommen fast keine darstellungsfehler und fast keine ausnahmen mehr.

Na, das sieht doch mal besser aus als die Screenshots im OP. Das oben zum Download verlinkte .jar hab ich aus der cloud genommen. Für mich ist dieses jar wie gesagt ein “Beiprodukt”, entstanden aus meinem Versuch, MV für Win32 zu bauen. - Das, was Dir geholfen hat war wohl dann eher Hinweis von @DerReisende77 auf ein JDK mit JavaFX für linux-arm32… keine Ahnung.

Ich habe für den inoffiziellen Build gegen Java 11.0.6 mit zugepacktem JavaFX gebaut (also JavaFX 11.0.6)
Die MV-Entwickler machen das anders, wie Du am pom.xml siehst (L73-L77). Dort wird mit JavaFX von org.openjfx v14-ea+6 gebaut. Und gerade vorhin hat @DerReisende77 betont, dass für den offiziellen Build aus gutem Grund 14-ea+6 verwendet wird, was -ich übersetZitiere hier- unter anderem mit fehlerhafter Darstellung von Dialogen in KDE zu tun habe.

Analog gedacht, eine möglichst hohe JavaFX Version einzusetzen mit möglichst vielen Bugfixes, ist ggfs. Java 13.0.2 einen Schuss ins Blaue wert? Aber ob die auch für JavaFX 14 einen early access build für RPi anbieten, so wie damals für ea 13 4… kann ich nicht sagen.

Ich hatte vor einer Weile für @DerReisende77 auf meinen (amd64) Linux VMs getestet, ob der o.g. GDK_SCALE Vorteile bringt gegenüber dem in der Anleitung genannten Java VM-Parameter uiScale (muss für Linux ganzzahling sein!)… konnte aber keine Vorteile erkennen. Bei meinen Linux amd64 VMs skaliert beides, GDK_SCALE und uiScale die komplette GUI um z.B. 200%. Schrift, Buttons, Swing-Anteile, JavaFX-Anteile - alles. Aber halt mit dem offiziellen Linux-Build von MV.

Ob es auf dem RPi, einem Gerät, das ich nicht habe, jetzt besser ist, ein gefixtes JavaFX (14ea6) für die falsche Plattform (64-bit) einzusetzen oder ein “ungefixtes” JavaFX (11u5 bzw. 13u2) für die richtige Plattform(linux-arm32)… ich bin hier eher raus aus der Nummer/Thread, insbesondere in Bezug darauf, Beiträge mit wenigstens einem Hauch von Ahnung verfassen zu können. - Java hat mir grade heute Vormittag mal wieder -in einem völlig anderen Kontext als MV- eine deutliche Wasserstandsmeldung gegeben, welchen “Kenntnisstand” ich tatsächlich habe. Ich bin mal wieder bedient und lass jetzt lieber die Erwachsenen sprechen.

Danke für den Test des “cross-build” jar (Win32 javac -> linux-arm32 Paket) trotzdem!

[beta-tester]

@rubikon
ich habe jetzt mal die 13’er version ausprobiert - eine 14’er early access version konnte ich nicht für mein RPi finden.
das verhalten von MV ist aber damit das selbe.

einen kurzen hoffnungsschimmer hatte ich bei der benutzung von parameter
-Dsun.java2d.uiScale=2.0.
damit hat sich ALLES um den faktor 2 vergrößert - auch die JavaFX sachen.
meine hoffnung war, mit -Dsun.java2d.uiScale=2.0 ALLES zu vergrößern und mit GDK_SCALE=0.5 nur die Gtk elemente wieder auf die ursprungsgröße runter zu skalieren… jedoch versteht GDK_SCALE leider nur ganzzahlige werte…

[beta-tester]

ach ja, mir ist aufgefallen mit der “richtigen” java version (bellsoft-JDK statt openJDK) ist auch das problem mit dem abspielen der videos aus MV heraus beseitigt
(die videos stocken nicht mehr und bild und ton sind nicht mehr so extrem versetzt).

[mvsfsvm]

@beta-tester was hat das mit der “richtigen” Javaversion zu tun? Hint: Das Abspielen erledigt doch eh ein externes Programm.

[beta-tester]

@mvsfsvm keine ahnung, ist nur so die feststellung, dass es nun viel geschmeidiger geht.
und in der zeit sind mir keine upgrades für VLC aufgefallen.
aber stimmt, da müsste ich jetzt die gegenprobe machen und zurück auf OpenJDK gehen und nocheinmal alles neu miteinander vergleichen.

[beta-tester]

was ist das denn jetzt :astonished_face:
ich habe die /boot/config.txt datei versehendlich gelöscht und nun ist die anzeige von MediathekView einwandfrei. alles sieht so aus wie es aussehen soll - einfach perfekt.
(diese config.txt datei ist bei dem RPi für bestimte grundkonfigurationen zuständig. unter anderem auch für die HDMI einstellungen) für die desktopbildschirmeinstellungen ist ein anderes programm zuständig, das aber scheinbar einige einstellungen doch von der config.txt datei benutzt.

sorry leute, da habe ich wohl irgendetwas in der config.txt datei gehabt, dass irgendwie die JavaFX scalierung aus dem tritt gebracht hat.
also die letzte hälfte dieses themas habe ich selber verbockt…
verzeihung… und danke für eure geduld und hilfe.

kann ich das thema irgendwo als gelöst markieren?

[beta-tester]

nur noch als anmerkung/zusammenfassung:

auf meinem Raspberry Pi 4 B mit 4GByte läuft MediathekView 13.5.x jetzt einwandfrei.

ich habe die MediathekView-latest-linux.tar.gz heruntergeladen und entpackt.

mit den standard paketen openjdk-11-jre + openjfx über debian/raspbian gab es massive darstellungsfehler.
deshalb habe ich das java paket bellsoft-java13-runtime-full von BellSoft installiert, statt den standard paketen openjdk-11-jre + openjfx über debian/raspbian:

wget -q -O - "https://download.bell-sw.com/pki/GPG-KEY-bellsoft" | sudo apt-key add -

echo "deb [arch=armhf] https://apt.bell-sw.com/ stable main" | sudo tee "/etc/apt/sources.list.d/bellsoft.list"

sudo apt update

sudo apt install bellsoft-java13-runtime-full

als MediathekView.desktop habe ich folgenden inhalt
(endweder den <dateipfad> anpassen oder $PATH anpassen)

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=MediathekView
Icon=MediathekView.svg
Exec=java -Xmx1G --illegal-access=warn --add-exports javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED -jar MediathekView.jar
StartupNotify=true

als warnung:
wenn in der /boot/config.txt datei die verwendung von EDID abgeschaltet wurde kann es stellenweise zu super kleinen schriften/elementen in MediathekView kommen, da der bildpunkte-pro-fläche-wert des bildschirms falsch angenommen wird, was wohl javafx elemente aus dem tritt bringt.

[beta-tester]

PS.: auch die folgene raspi-config einstellung lässt die javafx schriften/elemente zu klein erscheinen:
“7 Advanced Options -> A8 GL Driver -> G2 GL (Fake KMS) OpenGL desktop driver with fake KMS”

[beta-tester]

@mvsfsvm sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

@beta-tester was hat das mit der “richtigen” Javaversion zu tun? Hint: Das Abspielen erledigt doch eh ein externes Programm.

ja, du hast recht…
es ist mir in letzter zeit wieder vorgekommen, dass es abspielprobeme beim live abspielen gab.
es sind netwerkpeobleme… sorry für meine falschannahme.