[rpihddevice] skinnopacity und scrollende Texte

Zitat von Uwe

Hallo,
ich nutze das rpihddevice Plugin mit dem Skin "skinnopacity" auf meinen raspberry2.
Wenn ich die "epgsearch Plugin --> Jetzt"- Ansicht aufrufe und in einer Zeile einen Sendungsnamen habe, der etwas länger ist, wird dieser nach links gescrollt.
Nun zum Problem: Wenn ich mit dem Menubalken zur nächsten Sendung gehen möchte (Taste: up/down), dann passiert das nicht sofort, sondern er scrollt einen Moment weiter, bevor er mit dem Menubalken zur nächsten Sendung geht. Dadurch habe ich immer eine kleine Verzögerung, die ein wenig nervig ist.
Kann dies jemand nachvollziehen, was ich hier meine? Ist das normal?
Mit einen anderen VDR mit einer FF HD und dem Skin nopacity habe ich das Problem nicht.

Gruß, Uwe

Alles anzeigen

Hallo Uwe,

dieses von Dir beschriebene Verhalten kann ich bei allen von mir betriebenen Raspi-Modellen (B, B+, 2) in Verbindung mit nopacity-Skin bestätigen. Ich habe einen für mich akzeptablen Workaround gefunden, indem ich die Breite der EPG-Liste von 30% auf 50% erhöht habe. Dadurch reduziert sich die Anzahl jener EPG-Listeneinträge, die nicht mehr zur Gänze angezeigt werden können und ein Scrolling benötigen. Damit lässt es sich etwas flüssiger und entspannter durch die EPG-Liste navigieren.

Grüße,
Tux76

Moin,

ich denke, das liegt am Thread Handling der ARM Architektur. Das Scrolling läuft in einem eigenen Thread, beim Beenden des Scrollings muss erst mal dieser Thread gestoppt werden. Wenn der Thread aber gerade am laufen ist, kann es natürlich passieren, dass es ein bisschen dauert, bis der Thread die CPU freigibt und dann beendet werden kann.

Ciao Louis

Hm, am "Thread Handling der ARM Architektur" ist ueberhaupt nichts speziell, da ist nicht irgendwas besonders langsam. Ich wuerde hier - ohne es zu wissen - auf eine Eigenheit der Scrolling-Implementierung auf der Raspi-GPU tippen...

Gruss,
S:oren

Zitat von S:oren

Ich wuerde hier - ohne es zu wissen - auf eine Eigenheit der Scrolling-Implementierung auf der Raspi-GPU tippen...

Hm...beim Scrolling wird ja einfach der Drawport einer Pixmap pro Zeiteinheit um z.B. ein Pixel verschoben. Das mache ich im Skin. Die Raspi Highlevel OSD implementierung kann damit eigentlich nix zu tun haben...

Ciao Louis

Uebernimmt die Darstellung der verschobenen Pixmap dann nicht die GPU auf dem Raspi? Und der ansteuernde CPU-Thread wird sich dann vermutlich nicht beenden lassen, bis die GPU fertig ist.
Wenn das Skin-Plugin die Verschiebungen pixelweise ausfuehrt und nach jedem Schritt einen Abbruch vorsieht, dann muss ja irgendwo im Ausgabe-Plugin noch irgendwas gequeued sein, wenn die Verschiebung "nachlaeuft".

Aber wie gesagt, alles nur Vermutungen. Sollte sich am besten reufer mal ansehen.

Gruss,
S:oren

Kurzer Einwurf

Ich lese es so: im ersten Post geht es um den nativen "skin-nopacity" und nicht um den skindesigner skin nopacity.

Oder?

Gruß
Stefan

Zitat von fox71

Ich lese es so: im ersten Post geht es um den nativen "skin-nopacity" und nicht um den skindesigner skin nopacity.

So sehe ich das auch...macht aber nix, ist ja beides von mir

Ciao Louis

Zitat von S:oren

Uebernimmt die Darstellung der verschobenen Pixmap dann nicht die GPU auf dem Raspi? Und der ansteuernde CPU-Thread wird sich dann vermutlich nicht beenden lassen, bis die GPU fertig ist.
Wenn das Skin-Plugin die Verschiebungen pixelweise ausfuehrt und nach jedem Schritt einen Abbruch vorsieht, dann muss ja irgendwo im Ausgabe-Plugin noch irgendwas gequeued sein, wenn die Verschiebung "nachlaeuft".

Genau, die Pixmap wird dann von der GPU gezeichnet. Und reufer hat sein highlevel OSD so implementiert, dass die OpenVG Befehle "serialisiert" werden, indem die Zeichenbefehle in eine Queue geschiben werden und in einem eigenen Thread hintereinander abgearbeitet werden. Wenn ich so drüber nachdenke könntest du schon recht haben

Ciao Louis

Zitat von louis

Hm...beim Scrolling wird ja einfach der Drawport einer Pixmap pro Zeiteinheit um z.B. ein Pixel verschoben. Das mache ich im Skin. Die Raspi Highlevel OSD implementierung kann damit eigentlich nix zu tun haben...

Könnte es denn sein, dass hier nur ein Delay fehlt? Der Fehler klingt für mich wie damals wie beim skindesigner, wo der skin in einer Endlosschlaufe "ungebremst" die aktuelle Verschiebung (damals ging es aber um das Ein-/Ausblenden) berechnet und so die Pixmap um Bruchteile von Pixeln schiebt und die GPU-Kommandoqueue mit Befehlen zumüllt. Ohne GPU-Beschleunigung wirkt die CPU als natürliche Bremse und der Effekt wäre nicht sichtbar - da das Absetzen einer GPU-Operation im rpihddevice aber praktisch keine Zeit beansprucht, muss man da schon vorsichtig sein.

Gruss
Thomas

Moin,

Zitat von reufer

Könnte es denn sein, dass hier nur ein Delay fehlt?

ich hab mir das eben nochmal angesehen, das kann eigentlich nicht sein. Beim Skindesigner war der Fehler im Fade Out, da hatte ich eine falsche Bedingung für den Sleep drinn. An dieser Stelle ist das aber nicht der Fall...

Ciao Louis

Zitat von Uwe

Liegt es nun eventuell doch am Skinnopacity? Wo könnte ich suchen?

Ich habe mir mal den Code vom Skin angeschaut, aber ohne selber zu debuggen. Steht bei dir in der setup.conf menuScrollSpeed auf 0? In dem Fall würde der beschriebene Effekt auftreten und die Befehlsqueue "geflutet". IMHO sollte das im Skin gefixt werden, denn die OSD-Implementation als einzige "Bremse" zu nutzen ist unschön, bzw. falsch.

Gruss
Thomas

Hallo Uwe

Zitat von Uwe

Also liegt der Fehler in FrameTime=15, weil es mit FrameTime=30 wieder funktioniert? Man könnte ermitteln, ab wann das Problem nicht mehr auftritt(20,25...). Tritt hier dein beschriebene Effekt auf, das die Befehlsqueue geflutet wird?
Kann man das nicht im rpihddevice abfangen?

Ich habe mir das soeben genauer angeschaut. Ein Fluten der Befehlsqueue so wie ich es im Verdacht hatte tritt nicht auf (ausser der menuScrollSpeed würde auf 0 gesetzt). Aber der Skin benutzt relativ viele Pixmaps die bei einem Flush() alle neu gezeichnet werden müssen. Dadurch entstehen auch mit Sleep() pro Durchgang einige Dutzend Meldungen die gequeued werden müssen. Scheinbar reicht das aus, um bei einer genügend hohen Framerate und Anzahl Pixmaps die Queue zu überfüllen - ich werde bei Gelegenheit mal schauen, ob ich da was optimieren kann.

Allerdings sind 15ms-Frameabstand (entspricht 66Hz) dafür auch eher sportlich angesetzt und der Unterschied zu 30ms dürfte kaum sichtbar sein. Zumal ich das Gefühl habe, dass die Funktion falsch implementiert ist: Als Benutzer erwarte ich unter "menuScrollSpeed" die Geschwindigkeit des Scrollens, während im Code (nach meinem Verständnis) nur die Framerate danach gesetzt wird - oder habe ich etwas übersehen?

Gruss
Thomas

Moin,

hm, die 15ms sind wahrlich nicht optimal. Wenn ein Flush eh länger dauert, zieht die Wartebedingung gar nicht. Aber du hast ja einen Workaround Da ich den nativen nopacity nicht mehr weiter entwickle, werde ich in nopacity da nichts mehr ändern, mal schauen ob ich das im Skindesigner noch optimieren kann.

Ciao Louis