Aber cNopacity ist doch ein cSkin und kein cOsdObject!?
Du hast recht, das kann nicht funktionieren. Ich weiß jetzt auch warum ich das gedacht habe, ich hatte die Debugausgabe an einer anderen Stelle eingebaut.
Den vorletzten Commit streiche ich komplett und das Start() nehme ich auch wieder raus.
Ich passe das im Anschluss mal an.
Grüße
kamel5
Die genauen Zusammenhänge habe ich da auch noch nicht erkannt.
Ich hatte da eine Debugausgabe eingebaut und jedesmal wenn ich das Menü oder eine andere Anzeige aufgerufen habe, wurde diese Funktion aufgerufen.
Was ich auch nicht verstehe, das es bei mir funktioniert und bei Dir nicht.
Ich würde mal den vorletzten Commit ausklammern. Ich probiere das morgen noch mal. Und mit dem letzten Commit funktioniert das ja.
Warum ist damit aber die Geometrie noch falsch?
Grüße
kamel5
Show(void) wird in osdbase.h definiert.
Grüße
kamel5
Mhhh, was ist bei Dir anders als bei mir.
Zumindest mit dem letzten Commit vom Devel-Light konnte ich bei meinen Tests keine Anzeigeprobleme feststellen.
Kannst Du vielleicht mal eine Bildschirmkopie machen, damit ich eine Vorstellung habe, was da nicht stimmt.
Ist das eventuell Theme-abhängig.
Grüße
kamel5
ist das nicht ein Gedankenfehler, dass Timeshiftaufnahmen mit einem @ beginnen ?
Eigentlich nicht. Das sind 2 verschiedene Sachen:
- 1. Wenn z.B. der Permashift-Patch aktiv ist oder ohne Patch die Pausentaste gedrückt wird, legt der VDR eine Timeshift-Aufnahme an, die mit einem "@" beginnt. Diese Aufnahme kann auch mehrere Sendungen enthalten und wird prinzipiell auch sofort wieder gelöscht, wenn man auf Stop drückt. Das würde ich Timeshift-Aufnahme nennen.
- 2. Wenn ein Timer angelegt wurde und man diese Aufnahme, die noch nicht beendet wurde, schon ansieht, ist das eigentlich keine Timeshift-Aufnahme.
Das ist aber auch egal. Ich will ja nichts ausbauen, was schon mal da war.
Du möchtest im Prinzip in so einem Fall die Endzeit der laufenden Aufnahme mit berücksichtigt sehen.
Ich schaue mal, wie ich das vernünftig wieder unterbringe.
Grüße
kamel5
S:oren ,
der Fehler müsste jetzt in Devel-Light im letzten Commit behoben sein.
Da hatte ich etwas zu kurz gedacht mit der letzten Anpassung, osdLeft und osdTop muss bei jeder Geometrieänderung natürlich auch geprüft und gesetzt werden.
Grüße
kamel5
Leider wird timeshift bei mir nicht mehr erkannt
OK, kannst Du mir sagen, mit welcher Version es noch ging? Und welchen Skin Du nutzt?
Grundsätzlich ist es bei Timeshift so, das nicht auf einen Patch geprüft wird, sondern nur das erste Zeichen einer Aufnahme. Wenn dieses Zeichen ein "@" ist, wird davon ausgegangen, das eine Timeshiftaufnahme vorliegt. Du müsstest also mal schauen, ob die Aufnahme bei Timeshift dieses Zeichen am Anfang hat. Außerdem kannst Du mal mit dem Skin estuary4vdr prüfen, ob es damit geht. Damit hat es bei mir funktioniert.
Grüße
kamel5
Ich kann nochmal in den Code reinschauen, aber nicht mehr heute...
Ich habe gerade nochmal getestet und denke, ich habe den Fehler schon gefunden (Menü wird links oben dargestellt).
Ich ändere das morgen Nachmittag und fasse die beiden anderen Patches zusammen.
Grüße
kamel5
Mist...
Eine Zeile vergessen und schon funktioniert das nicht richtig. 
Ich muss wirklich alles doppelt testen.
Ich habe den Devel-Light upgedated, jetzt sollte es übersetzen.
Soll ich ein bisect starten?
Das wäre nett.
Grüße
kamel5
Was funktioniert da nicht richtig? Mir ist bisher nichts aufgefallen...
Ich habe mal einen Branch Devel-Light angelegt. Da sind die dazu gehörenden Änderungen und noch einige Andere, die auch für die Light-Version passen sollten, enthalten.
Grüße
kamel5
Was funktioniert da nicht richtig? Mir ist bisher nichts aufgefallen...
Das fällt nur bei bestimmten Themen auf. Das Problem war hier, das die Grafiken für den imagecache bei der Initialisierung erzeugt wurden. Zu dieser Zeit war allerdings dem VDR der Skin und damit auch das Theme noch nicht bekannt. Das war auch der Grund für die ursprüngliche Implementierung mit dem CreateCacheDelayed in displaychannel.
Die letzten beiden Commits in meinem Devel-Branch sollten das beheben.
Den Devel-Branch bitte neu herunterladen, ich habe da nach Deinen Hinweisen noch ein wenig geändert.
Hab ich am Wochenende mal gefixt,
Mal schauen, ob ich das für master so übernehmen kann.
Grüße
kamel5
Danke für die Rückmeldung.
Ich werde mir das im Skin aber trotzdem nochmal anschauen, weil das ständige Aufrufen dieser Funktion ja nicht sein muss.
Grüße
kamel5
ich habe mir das Video mal angesehen und hier getestet. Bei mir ist das nicht so. Funktioniert das denn bei anderen Skins mit Video im Fenster?
Im Moment sehe ich da auch nicht wirklich eine Möglichkeit, wie das vom Skin aus beeinflusst werden könnte.
Wenn z.B. das Hauptmenü geöffnet wird, wird das Video auf eine feste Größe skaliert. Wenn man dann nichts bedient, ändert sich die Größe auch nicht weiter.
Da bei diesem Skin allerdings die Skalierungsfunktion auch bei unveränderter Größe öfter aufgerufen wird, wäre das die einzige Möglichkeit, das damit das Ausgabedevice überfordert wird.
Um das Einzugrenzen könntest Du mal folgenden Patch auf den master einspielen:
diff --git a/displaymenu.c b/displaymenu.c
index a97bc93..dde5f28 100644
--- a/displaymenu.c
+++ b/displaymenu.c
@@ -713,10 +713,11 @@ void cNopacityDisplayMenu::Flush(void) {
if (FadeTime)
Start();
}
+ if (initial)
+ cDevice::PrimaryDevice()->ScaleVideo(videoWindowRect);
initMenu = false;
initial = false;
osd->Flush();
- cDevice::PrimaryDevice()->ScaleVideo(videoWindowRect);
}
void cNopacityDisplayMenu::Action(void) {Damit wird die Skalierungsfunktion nur einmalig beim Aufruf z.B. des Menüs benutzt. Wenn es damit auch nicht geht, liegt es möglicherweise doch am Ausgabedevice.
Diese Änderung nur zum Testen benutzen, da dann später nicht neu skaliert wird.
Grüße
kamel5
es gibt einen Eintrag in der HISTORY (wieso ist da die Reihenfolge der Versionen jetzt so merkwierdig?) dazu.
Ich hatte mal angefangen, die neuesten Einträge nach oben zu nehmen, damit man beim Öffnen gleich den letzten Stand sieht. Das muss ich mal vollenden.
Vermutlich werden die Distri-Leute recht ungluecklich, wenn es 2 aktive Branches in einem Plugin gibt.
Da würde ich mir im Moment nicht so viel Gedanken darüber machen. Das gibt es bei anderen Plugins auch schon.
Wenn nötig, kann die light Version auch einen neuen Namen bekommen, zB. skinnopacitylt.
Bisher mehr Ideen als Patches. Aber wenn ich mich da austoben darf, kann ich mir vielleicht mal Zeit nehmen.
Immer zu. Dann kümmere ich mich erst einmal weiter um den master Branch und übernehme passende Sachen auch in die light Version.
Heute ist mir auch noch ein Bug mit Grafiken in beiden Versionen aufgefallen, den muss ich mal endgültig fixen.
Grüße
kamel5
Wie loest man diesen Widerspruch am besten? Gute Frage!
Waere interessant, welche Features der verschiedenen Skins wirklich aktiv genutzt werden.
Ja, das wird man aber wohl nicht erfahren. Es gibt hier im Forum einfach zu wenige, die dazu mal was posten, da die meisten sicher eine fertige Distribution benutzen.
Ich selber nutze diesen Skin auch nicht, auch keinen Skindesigner Skin, nur das TVGuide-Plugin (das funktioniert mittlerweile auch recht gut mit der TT6400) von Louis. Als Skin habe ich mir einen etwas angepassten LCARS-Skin gemacht, ja das ist nicht jedermanns Sache, aber für meine Zwecke mit der TT6400 ideal. Da hätte ich aber gern noch ein paar Sachen und das hier ist dazu meine Spielwiese, mal zu schauen, was geht und was nicht so toll geht.
Das vertraegt sich leider nicht mit Deinem Ansatz, noch mehr Konfigurierbarkeit einzubauen und alle bestehenden Erker beizubehalten. Und dann sogar den Code der schon jetzt verschiedenen Plugins wieder zu vereinheitlichen. Das kann die vorhandene Komplexitaet nur weiter steigern.
Das war nur so eine Idee. Ich hätte auch kein Problem damit, die Light-Version abgespeckt separat fortzuführen und den master noch etwas zu optimieren, aber grundsätzlich so zu lassen. (Der letzte Stand vom Devel-Branch läuft auf meiner x86 Hardware mit der TT6400 doch recht zügig.) Für beide Varianten gibt es sicher eine Zielgruppe.
Den damals fuer mich größten Performancekiller konnte ich durch Einbringen eines einfachen und schnellen Image-Skalers beseitigen.
Das würde mich auch interessieren, was Du da gemacht hast.
Wenn Du also noch Patches hast für den light_version Branch, immer her damit.
Grüße
kamel5
Ich hoffe, ich habe mich jetzt nicht zu unbeliebt gemacht...
Also nicht bei mir. Als Hobby-Programmierer, der sich das in Self Made Manier angeeignet hat, ist man für jeden konstruktiven Hinweis dankbar.
Nur warum gibt es 2 Patches mit dem selben Titel? Zuerst den zweiten Teil vergessen? Dafuer gibt es 'git rebase -i' und "fixup"...
Das habe ich kommen sehen...
Nicht vergessen, nur vor dem Upload vergessen, zusammenzuführen...
In Umbenennungen sehe ich keinen Wert, aber ich kenne auch die anderen Skins nicht
Das mag im Allgemeinen richtig sein. Bei Louis Plugins wiederholt sich allerdings Vieles, so habe ich es dann einfacher, Dinge zu vergleichen.
Wie ich es gelernt habe, gehoeren Whitespace-Cleanup und funktionale Aenderungen (long -> int in for-Schleifen) nicht in einen Patch.
Das habe ich nicht ganz verstanden.
- "Cleanup menuView declaration"
Das halte ich fuer einen Fehler. Globale Variablen sind immer eher schlecht. Hier wird auch noch eine Klasse DisplayMenuView, die nur in DisplayMenu benutzt wird, global abgelegt. Ergibt fuer mich wenig Sinn. Fuer mich gehoert die ganze Klasse DisplayMenuView komplett in die Klasse DisplayMenu integriert. Macht alles viel einfacher und erlaubt weitere Codeoptimierungen.
Das ist auch mein Ziel. Im Moment wollte ich damit nur die Zusammenhänge besser verstehen.
- "Eliminate detailView in cNopacityDisplayMenu"
Das verstehe ich nicht, da fehlt mir zumindest eine Erklaerung. Auch bläht es den Code extrem auf, erscheint mir nicht sinnvoll. Scheint auch neue Threads zu erzeugen, was ich fuer einen großen Fehler halte (langsam, fehleranfaellig, unuebersichtlich).
Neue Threads macht das nicht, es ist immer nur einer aktiv. Und dient erst einmal auch zum besseren Verständnis.
- "Faster display info"
Auch wieder ein zusaetzlicher Thread, wobei ich gar nicht sehe, wo der gestartet wird.
Auch kein neuer Thread.
Hier ist eigentlich nur die Änderung in displaymenu.c wichtig. Die eigentliche Ursache für das "Powerpoint" ähnliche Verhalten lag an diesem Flush.
In dem es jetzt bei laufenden Threads nicht mehr aufgerufen wird, wird dieser Effekt eliminiert.
Jetzt sehe ich auch, was Du mit den neuen Threads meinst. Das sind keine neuen Threads, das dient nur zur eindeutigen Identifikation in den Logs, diese Threads gab es vorher auch schon.
Nach der "reinen Lehre" soll ein Skin nur darstellen, was der VDR vorgibt. Dabei soll ein Skin keine zusaetzlichen Flush()-Operationen erfinden (was bei der S2-6400 extrem langsam ist), sondern nur dann einen osd->Flush() ausfuehren, wenn vom VDR ein Flush() angefordert wird. Das ist hier, was die Performance-Verbesserung bringt.
Wie schon vorher geschrieben, den 1.1.x-Branch mit den ganzen Threads halte ich fuer kaputt. Der 1.0.x-Branch funktioniert fuer mich ohne "Powerpoint-Effekt", nur diesen Branch finde ich als Ausgangspunkt fuer weitere Entwicklungen geeignet (ein paar Ideen haette ich da noch).
Ja, in einer idealen Welt... Leider wollen viele Anwender halt ein Bling-Bling.
Deshalb kann ich diese zusätzlichen Sachen auch nicht einfach wieder ausbauen, dann beschwert sich bestimmt jemand.
So werde ich das Ganze wohl konfigurierbar machen müssen...
Grüße
kamel5
...habe mir den Devel-Branch auch mal installiert. 😉
Nutze eine FF HD 6400 auf einem Arm-Matrix (imx6 Quadcore).
Beim laden der Aufnahmeinfo bekomme ich folgendes:
Die Fehlermeldung kannst Du erst einmal ignorieren.
Im Moment geht es im Devel-Branch um das zeitversetzte Auftauchen von Informationen, z.B. bei der Programminfo oder Recordingsinfo.
Insgesamt ist der Skin sehr zäh... deshalb wohl der Devel-Branch?!
Na ja, was bedeutet zäh? Der Skin ist schon Resourcenintensiv, vor allem, wenn auch Bilder angezeigt werden.
Ich nutze auch die TT6400, allerdings mit x86, da funktioniert das schon recht ordentlich, wenn man die Einblendzeiten auf 0 stellt. In den Menüs z. B. kann ich keine Verzögerungen feststellen.
Grüße
kamel5
S:oren ,
ich denke, ich habe jetzt die eigentliche Ursache für das "Powerpoint" ähnliche Verhalten gefunden.
Beim Aufruf von Detailinformationen (Info) haben sich zwei Flush-Aufrufe behindert.
Ich habe dazu mal einen Branch Devel unter gitlab.com/kamel5/SkinNopacity angelegt.
Der letzte commit enthält die wichtige Änderung in displaymenu.c.
Es wäre schön, wenn Du das mal auf Deiner Hardware testen könntest.
Ich habe dazu auch eine Logmeldung eingebaut, die den Zeitbedarf an der wichtigen Stelle zeigt.
[109333] view.c DrawHeader 107 21msVor dieser Änderung lag der Zeitbedarf hier bei ca. 600...800ms und das führte dann zu dem langsamen Aufbau.
Grüße
kamel5
Ich kenne mich nicht aus, aber so was ähnliches ist drin glaub ich
Ja, das ist vergleichbar. Bei den neueren Versionen von *magick soll das im constructor gemacht werden, ist also wohl die bessere Lösung und wird in weiteren Plugins auch so gemacht.
Grüße
kamel5
