Flush()-Intervalle in DisplayMenu

    Ich habe mal ne Frage an die Insider:


    Ich versuche in einem Skin Text-Scrolling zu implementieren und wundere mich, dass DisplayMenu::Flush() auf einem Rechner alle 28ms aufgerufen wird, auf einem anderen (gleiche libvdr) aber nur ca. alle 1040ms, also nach über 1 Sekunde. Damit "scrollt" es aber nicht mehr sondern springt ...


    In den VDR-Quellen und mit der Suche hier im Portal habe ich keinen Hinweis gefunden. Kann mir jemand auf die Sprünge helfen?


    Ach ja, DisplayChannel, DisplayReplay etc. funktionieren alle gut, nur DisplayMenu hat diese großen Flush-Intervalle...


    Außerdem wird das DisplayMenu alle 6 Sekunden gelöscht und komplett neu aufgebaut - auch wenn sich nichts geändert hat. Kennt jemand dafür den Grund?


    FireFly

    Hallo FireFly!



    Keine Ahnung. Ich habe sogar manchmal den Fall, dass DisplayMenu::Flush() ununterbrochen aufgerufen wird, solange bis das Menu gewechselt wird. Passiert mit Standard-VDR und Classic-Skin.
    Ein Tipp am Rande: Für's Scrolling wirst Du vermutlich nicht ohne Threads auskommen.


    Zitat

    Außerdem wird das DisplayMenu alle 6 Sekunden gelöscht und komplett neu aufgebaut - auch wenn sich nichts geändert hat. Kennt jemand dafür den Grund?


    FireFly


    Soweit ich weiß ist das nur im Hauptmenü so, damit die Plugins ihren Hauptmenü-Eintrag ändern können, z.B. beim Burn-Plugin.


    Gruß,
    Andreas

    Zitat

    Originally posted by FireFly
    Ich versuche in einem Skin Text-Scrolling zu implementieren und wundere mich, dass DisplayMenu::Flush() auf einem Rechner alle 28ms aufgerufen wird, auf einem anderen (gleiche libvdr) aber nur ca. alle 1040ms, also nach über 1 Sekunde.


    Ich tippe darauf, dass es davon abhängt, ob das aktuelle cOsdObject (Menü, etc.) ein NeedsFastResponse() meldet. Danach entscheidet VDR, ob er den Hauptthread 1000ms oder nur 10ms auf eingehende Tastendrücke schlafen lässt. Entsprechend schnell oder langsam ist dann auch die Zykluszeit der Hauptschleife.


    Gruß,


    Udo

    Danke für die beiden schnellen Antworten.


    Zitat

    Original von Urig
    Ich tippe darauf, dass es davon abhängt, ob das aktuelle cOsdObject (Menü, etc.) ein NeedsFastResponse() meldet. Danach entscheidet VDR, ob er den Hauptthread 1000ms oder nur 10ms auf eingehende Tastendrücke schlafen lässt.


    In der Tat scheint es so zu sein, dass in cInterface::GetKey das

    Code
    return cRemote::Get(Wait ? 1000 : 10);

    für die unterschiedlichen Intervalle verantwortlich ist (und das Wait ist das Ergebnis von NeedsFastResponse())


    Trotzdem finde ich es seltsam, dass sich beide Rechner bei den gleichen Menüs so unterschiedlich verhalten.


    Zitat

    Original von amair
    Für's Scrolling wirst Du vermutlich nicht ohne Threads auskommen.

    Das habe ich befürchtet, wollte es aber möglichst vermeiden ....


    FireFly

    Hi!


    Zitat

    Original von FireFly
    Nochwas: während ein SetEvent/SetRecording oder auch Flush läuft kann doch kein weiterer Flush aufgerufen werden, oder? Demnach bräuchte man das Flush auch nicht gegen einen nochmaligen Aufruf von Flush abzusichern (wie ich es schon mal gesehen habe), oder?


    Wenn Du meinst, dass Du es im EnigmaNG gesehen hast:
    doch, das muss abgesichert werden, da der Scroll-Thread auch Flush() aufruft.


    Wenn Du in einem eigenen Thread auf das cOsd-Objekt zugreifst, also potentiell gleichzeitig zum Haupt-Thread, mußt Du IMHO alle Zugriffe auf cOsd syncen.


    Gruß,
    Andreas

    Zitat

    Original von amair
    Wenn Du meinst, dass Du es im EnigmaNG gesehen hast:


    Nee, das war im SkinElchi und da wird z.B. auch im DisplayChannel das Flush() gesichert so dass während der Konstruktor oder Flush() ausgeführt wird kein weiteres Flush() ausgeführt werden kann. Da das aber alles aus einem Thread (dem Hauptthread) aufgerufen wird, ist das doch nicht notwendig oder? Sobald Threads ins Spiel kommen sieht das natürlich anders aus ...

    Hi,


    Zitat

    Original von FireFly
    Nee, das war im SkinElchi ...


    Unsinnig waren die sicher irgendwann auch nicht, da gab's zumindest ursprünglich auch eine Zeile für Logeinträge, die ich dann auch im Log gefunden hab.


    Im Menü hatte ich auch mal was mit einem Thread versucht, dies aber für's Release immer auskommentiert und letztlich zwar nicht weiterverfolgt, aber auch nicht ganz verworfen.


    Ich warte ja noch ein wenig drauf, was Du so draus machst ;)


    Frank

    Hallo _Frank_ :lachen3


    wie Du siehst habe ich es immer noch nicht aufgegeben, auch wenn ich das letzte halbe Jahr nicht so viel Zeit dafür hatte.


    Ich mache halt etwas Reverse-Engineering um rauszufinden, warum das so programmiert wurde ...


    So wie ich das in pre2 sehe, wird in DisplayMenu ein zusätzlicher Thread gestartet, der regelmäßig ein Skins.Flush() aufruft, aber auch das hilft nicht bei meinem Zweitrechner. Ich hatte gehofft mir an dieser Stelle das Threading sparen zu können ...


    Gruß
    FireFly

    Wie im anderen Thread angedeutet bestimmt nicht der VDR-Kern, sondern jenes Coding, welches Infos auf einem Skin ausgibt, wie oft Flush() aufgerufen wird. Ob das indirekt über Tastendrücke des Users oder direkt geschieht ist erstmal egal. Das heißt aber man kann hier keinerlei Annahmen machen, wenn man eine bestimmte Frequenz wünscht, muss ein eigener "Taktgeber" (Thread) her.


    (Angeregt durch den anderen Thread, der auch hierhin verlinkt, wollte ich nochmal ein Fazit bringen :) )

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden