MaxPixmapSize per default auf 2048x2048?

    Hallo,


    da ich seit neuem auch mit einem RPI TV schaue ist mir folgendes Problem aufgefallen.

    In meinem Skin flatPlus verwende ich Pixmaps. Bei großen Pixmaps ist ein Scrolling möglich und diese Pixmaps werden gerne mal größer als 2048x2048 Pixel. Der RPI unterstützt aber nur max. 2048x2048 Pixel. Wenn ich ein größeres Pixmap anfordere schmiert gleich der ganze VDR ab.


    Dieses Problem wurde ja schon von Klaus erkannt und es gibt die Funktion MaxPixmapSize seit vdr 2.4.


    Nun wollte ich mich daran machen und mein Skin RPI safe machen. Nun ist mir aber aufgefallen das im Default MaxPixmapSize 2048x2048 zurückgibt. Ist dies wirklich so klug gewählt? Softhddevice z.b. hat die Funktion noch nicht implementiert also wird bei Softhdddevice 2048x2048 zurück gegeben. Wenn ich das jetzt einbaue dann wird nicht nur beim RPI das Pixmap begrenzt sondern auch bei allen anderen Ausgabedevices die die Funktion noch nicht implementiert haben (wie softhddevice).


    Wäre es nicht z.B. besser per default 0x0 zurückzugeben und das bedeutet halt unendlich weil das Ausgabedevice es nicht implementiert hat?


    Grüße

    Martin

    Hallo Martin


    Die 2048x2048px gelten ja "nur" für die default-Implementation des un-beschleunigten OSDs und sind, streng genommen, vom Arbeitsspeicher des VDR abhängig. Ob das jetzt mehr oder weniger sein soll lässt sich sicher diskutieren, aber unendlich fände ich auch komisch...


    Gruss

    Thomas

    Danke für die Antwort, eEine Diskussion ist ja genau das was ich anstoßen möchte. Wie gesagt das jetzige Verhalten finde ich nicht richtig da 2048x2048 per default nicht die Realität wiederspiegelt. Wie du schon sagst ist es (außer beim rpi) vom RAM abhängig und dort ist in der deutlich mehr möglich.

    Vielleicht kann man sich auch auf 9999x9999 Pixel einigen. Vielleicht übersehe ich auch noch etwas. Deswegen würde ich gerne noch mehr Meinungen und insbesondere Klaus hierzu hören.


    Grüße

    Martin

    Ich sehe hier nicht die Himbeere als Spezialfall, eher die SW-Implementation des VDR. Hat nicht auch OpenGL eine maximale Grösse für Pixmaps? Spätestens bei Embedded-Systemen (z.B. Odroid) dürften die Grenzen real werden.


    So oder so sollten sich Skin-Entwickler darum kümmern. Ob die Grenze nun bei 2k oder mehr liegt, spielt dabei ja keine Rolle - je höher der Default-Wert, desto eher wird das Problem verdrängt und lässt die Nutzer von Früchtekuchen potentiell aussen vor.


    Gruss

    Thomas

    Zitat von reufer

    So oder so sollten sich Skin-Entwickler darum kümmern.

    1. Ich möchte mich gerade darum kümmern :)

    2. Braucht der Skin nunmal die max. Grenze wenn es denn eine gibt. Und wenn es eine Grenze gibt, wird die nicht vom Skin vorgegeben sondern vom Ausgabedevice.


    Also die Verantwortung einzig auf den Skin abzugeben kann nicht die Lösung sein.


    Grüße

    Martin

    Ich weiss nicht, ob ich dich richtig verstehe. Ist es nicht so, dass es immer eine Grenze gibt? Ob die nun bei 2k oder mehr liegt, spielt ja keine Rolle. Ein Skin muss einfach damit umgehen können, wenn die verwendete OSD-Implementation die angeforderte Pixmap nicht liefern kann. Wenn es ums Scrollen von EPG-Informationen geht (das war damals bei der Einfürung der Grenze der konkrete Anlass), hat Klaus ja im osddemo-Plugin vorgemacht, wie sich das mit minimalem Überhang realisieren lässt.


    Gruss

    Thomas

    Zitat von mini73

    Und in softhddevice und Abarten einfach die entsprechende Funktion implementieren. Muss ja sowieso gemacht werden...

    Da bin ich auch für aber hier stellt sich die Frage auf welchen Wert? Soweit ich das in einem anderen Thread mitbekommen habe gibt es keine wirkliche Grenze sondern wird vom RAM begrenzt. Also auf welchen Wert stellen?

    Und wenn wir dort irgendeinen fiktiven Wert nehmen warum dann nicht auch als default im VDR Core?

    Wenn man sich auf einen Wert ala "unendlich" einigt, könnte dieser der default im VDR Core werden und nur wenn ein Ausgabeplugin eine "echte" Grenze hat kann das Plugin diesen Wert überschreiben.


    Grüße

    Martin

    Unendlich gibt es nicht in der Computerwelt. Viel mehr als die Displaygröße und etwas Rand braucht man nicht. Deshalb finde ich den aktuellen Wert auch gar nicht so schlecht.


    Ansonsten muss das Ausgabeplugin irgendwie herausfinden, was möglich ist. Oder man baut es konfigurierbar ein, wenn man keine Logik einbauen möchte. Dann darf der Anwender da für sein System passende Zahlen eintragen. Wäre ja auch im vdr denkbar. Wenn etwas in der setup.conf steht, das als default rausgeben, ansonsten 2048x2048.


    Du musst sowieso mit einer beschränkten Größe zurechtkommen.


    Lars

    Hallo,


    ich verstehe worauf Du hienaus möchtest und gebe dir in Prinzip auch Recht.

    Aber bis letztes Jahr musste sich kein Skin gedanken über die max Größe der Pixmap machen und dementsprechend nutzen die Skins dies auch aus. Das ist nicht nur bei Skin flatPlus der Fall und bei anderen Ausgabedevices hat man derzeit auch keine Probleme.


    Ich wollte jetzt für rpihddevice das MaxPixmapSize implementieren damit der VDR nicht mehr abstürzt. Wenn ich dies aber so umsetze sind alle anderen Nutzer die softhddevice oder ähnliches verwenden die angearschten weil bei denen die Pixmaps auch auf 2048x2048 abgeschnitten werden und dann Funktionen wie Scrollende Texte (bei langen Texten) nicht mehr funktionieren.

    Dies wollte ich nur vermeiden aber dann schiebe ich das Problem auf das Ausgabedevice und die müssen halt irgendwelche Werte für MaxPixmapSize eintragen oder es findet sich doch noch ein kompromiss den default Wert im vdr core zu erhöhen :P


    Ich weiß ich könnte auch eine "richtige" Lösung implementieren die dann mehrere Pixmaps hintereinander verwendet oder so, dafür habe ich derzeit aber leider keine Zeit ...


    Grüße

    Martin

    Wenn ich mich richtig erinnere wurde cOsd::MaxPixmapSize() seinerzeit wegen Problemen mit zu großen Pixmaps beim Raspberry Pi eingeführt. Interessanterweise wird der Standardwert von 2048x2048 in der default Implementierung von cPixmapMemory gar nicht kontrolliert. Man könnte also unter Ignorierung von MaxPixmapSize() beliebig große cPixmaps anlegen ;-).


    Da eine Pixmap ein hardware-implementiertes Objekt sein kann, macht es schon Sinn, dass es da eine Obergrenze für die Größe gibt. Beim RasPi ist die nunmal 2048x2048. Das heißt, wenn wir den Defaultwert vergrößern, dann könnte man zwar mit softhddevice vielleicht größere Pixmaps anlegen, aber auf dem RasPi würde das dann nicht funktionieren (damit wären die RasPi-Benutzer die "angearschten" ;-).


    Mal angenommen, der Defaultwert wäre "unendlich", was würdest du denn dann in deiner Skin flatPlus machen, wenn auf dem RasPi 2048x2048 als Maximum angegeben wird?


    Eine mögliche Lösung für vertikales Scrolling von Texten ist im osddemo-Plugin mit ScrollPixmap gezeigt.

    Für einen horizontal scrollenden Text könnte ich mir vorstellen, diesen einfach in mehrere cPixmaps, die maximal MaxPixmapSize groß sind, auzuteilen und diese hintereinander "durchzuschieben".


    Klaus

    Zitat von kls

    Das heißt, wenn wir den Defaultwert vergrößern, dann könnte man zwar mit softhddevice vielleicht größere Pixmaps anlegen, aber auf dem RasPi würde das dann nicht funktionieren (damit wären die RasPi-Benutzer die "angearschten" ;-).

    Aber das rpihddevice überschreibt doch MaxPixmapSize mit 2048x2048 und dann währe doch alles gut. Also wenn im vdr core meinetwegen 9999x9999 eingestellt ist dann haben alle Ausgabedevices diesen Wert. Rpihddevice (und in Zukunft vielleicht andere) überschreiben den Wert mit ihrer tatsächlichen Grenze.


    Zitat von kls

    Mal angenommen, der Defaultwert wäre "unendlich", was würdest du denn dann in deiner Skin flatPlus machen, wenn auf dem RasPi 2048x2048 als Maximum angegeben wird?

    Ich hatte jetzt vor MaxPixmapSize abzufragen und bei CreatePixmap diesen als maximale Größe zu verwenden. Wenn ich also eigentlich ein größeres Pixmap anfordern würde für scrolling oder so, wird es halt abgeschnitten und Scrolling funktioniert dann nicht. Aber zumindest stürzt der VDR nicht mehr ab. Ist jetzt die schnellste und einfachste Lösung für mich :)


    Grüße

    Martin

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden