Hallo,
es macht ja keinen Sinn die erste Anzeige von skinnopacity komplett zu unterdrücken, deshalb habe ich das Handling der Kanalanzeige nochmal etwas optimiert.
Also bitte nochmal den letzten commit testen, ob das so bleiben kann.
Grüße
kamel5
[SkinNopacity] Aktuelle Probleme
-
kamel5 Werde ich prüfen, Danke auch dafür!
Hattest du diese Patches mit eingebaut?
- URL: helpers.c.diff Patch
- URL: SemaphoreInfo - Patch
Eventuell sind die nicht erforderlich...?
-
es macht ja keinen Sinn die erste Anzeige von skinnopacity komplett zu unterdrücken, deshalb habe ich das Handling der Kanalanzeige nochmal etwas optimiert.
Also bitte nochmal den letzten commit testen, ob das so bleiben kann.
Hallo kamel5,
hier funktioniert der Skin aus deinem git sehr gut! AUch beim Start kommt nun die Kanalinfo, Danke dafür!
Gruß
Uwe
-
Was mich jetzt noch beim skinnopacity stört:
Wenn man im Aufnahmemenu sich die Beschreibung (Info) der jeweiligen Aufnahme anschaut, dann wird die Info optisch zwei mal aufgebaut!
Vielleicht kann man dies auch noch beseitigen?! Oder jemand hat eine Idee, warum dies so ist?
Viele Grüße
Uwe
-
Mhh, wenn ich in der Liste der Aufnahmen mir die Beschreibungsdetails über die Info-Taste aufrufe, wird bei mir (zumindest sieht es so aus) das komplette Fenster 2mal aufgebaut. Auch beim ersten mal (Fenster-Aufbau inklusive Text) ist alles schon komplett zu sehen.
-
Hier ist der Thread, wo ueber die Weiterentwicklung von skinnopacity diskutiert wird. Den habt ihr aber gut versteckt
es macht ja keinen Sinn die erste Anzeige von skinnopacity komplett zu unterdrücken, deshalb habe ich das Handling der Kanalanzeige nochmal etwas optimiert.
Also bitte nochmal den letzten commit testen, ob das so bleiben kann.
Sehr schoen. Funktioniert einwandfrei auf einer S2-6400. Hatte es aber auch schon, bevor louis diesen Workaround fuer ein anderes Ausgabeplugin (kann mich nicht mehr erinnern, welches das war) eingebaut hat. Freut mich sehr, dass das wieder gefixt ist.
Das liegt daran, das die Info und alle anderen Daten in einem separaten thread nachgeladen werden und wurde damals bewusst so eingebaut.
Sehr aergerlich fuer mich. Deshalb habe ich skinnopacity jahrelang in der Version vor diesem Commit benutzt (mit vdr-2.2). Ich halte es fuer einen grossen Fehler, ein OSD Flush() aus mehreren Threads gleichzeitig unkoordiniert aufzurufen. So war das nie gedacht, funktioniert auf der HD-FF nur "aus Versehen ein bisschen".
Daten in mehreren Threads laden ist OK, ob es wirklich signifikant etwas bringt, weiss ich nicht. Aber Flush() sollte nur aus dem Haupt-Thread aufgerufen werden. Und auf der S2-6400 möglichst selten (am besten nur 1x pro OSD-Menue), weil das Kopieren der Daten auf die Karte sooo viel langsamer ist, als alle Berechnungen vorher. Mit den vielen Flush()-Aufrufen entsteht die beschriebene "Powerpoint-Animation" mit nacheinander auftauchenden Bildelementen. Finde ich grueselig. Hatte schon ein paar der Flush()-Aufrufe fuer mich herausgeloescht, bin aber noch nicht dazu gekommen, einen vernuenftigen Patch zu bauen, der die Threads koordiniert oder weglaesst. Sehr schoen, wenn Du das nochmal ansehen willst.
Ich kann diesen Effekt bei mir nicht erkennen.
Ich sehe im Wesentlichen auch nur den Effekt nacheinander auftauchender Bildteile. Aber wie ich das sehe kann ein Flush() aus einem Thread auch halb-gezeichnete Sachen aus einem anderen Thread mit darstellen, was zu den merkwuerdigsten Effekten fuehren kann.
Gruss,
S:oren
-
Hier ist der Thread, wo ueber die Weiterentwicklung von skinnopacity diskutiert wird. Den habt ihr aber gut versteckt
In dem Anderen war es ja noch mehr OT.
Sehr schoen. Funktioniert einwandfrei auf einer S2-6400.
Ich selber nutze ja auch noch die S2-6400, für mich im Moment immer noch das unkomplizierteste Ausgabe-Device. Ich teste auch alles damit.
Sehr aergerlich fuer mich. Deshalb habe ich skinnopacity jahrelang in der Version vor diesem Commit benutzt (mit vdr-2.2). Ich halte es fuer einen grossen Fehler, ein OSD Flush() aus mehreren Threads gleichzeitig unkoordiniert aufzurufen. So war das nie gedacht, funktioniert auf der HD-FF nur "aus Versehen ein bisschen".
Daten in mehreren Threads laden ist OK, ob es wirklich signifikant etwas bringt, weiss ich nicht. Aber Flush() sollte nur aus dem Haupt-Thread aufgerufen werden. Und auf der S2-6400 möglichst selten (am besten nur 1x pro OSD-Menue), weil das Kopieren der Daten auf die Karte sooo viel langsamer ist, als alle Berechnungen vorher. Mit den vielen Flush()-Aufrufen entsteht die beschriebene "Powerpoint-Animation" mit nacheinander auftauchenden Bildelementen. Finde ich grueselig. Hatte schon ein paar der Flush()-Aufrufe fuer mich herausgeloescht, bin aber noch nicht dazu gekommen, einen vernuenftigen Patch zu bauen, der die Threads koordiniert oder weglaesst. Sehr schoen, wenn Du das nochmal ansehen willst.
Ja, diese Effekte gefallen mir auch nicht. Ich versuche das für ein anderes Plugin schon seit geraumer Zeit zu lösen. So eine wirklich gute Lösung habe ich da aber auch noch nicht gefunden.
Man könnte jetzt zwar die ganzen weiteren Flush() einfach streichen, das würde aber bedeuten, das der nächste Flush() im ungünstigsten Falle erst nach einer Sekunde kommt und das kann eine gefühlte Ewigkeit sein.
Na mal sehen, was mir dazu noch einfällt.
Grüße
kamel5
-
Ich vermute, die ganze OSD-Library ist nicht thread-safe. Also dürfen genau genommen alle OSD-Aufrufe nur aus einem Thread kommen (nicht nur das Flush() ).
Eine Verzögerung habe ich gelegentlich im Aufnahmen-Menue, nirgends sonst. Da hattest Du auch schon irgendwo Patches, ich habe allerdings den Ueberblick verloren. Mach bitte neue Forum-Threads auf fuer solche Sachen, sonst geht das unter. Gibt es da noch Verzoegerungen, und wenn ja, wieso?
Gruss,
S:oren
-
Ich habe im letzten commit jetzt mal alle aus meiner Sicht unnötigen Flush()-Aufrufe auskommentiert, das sollte schon einiges Verbessern.
Mach bitte neue Forum-Threads auf fuer solche Sachen, sonst geht das unter.
Können wir gerne machen.
Eine Verzögerung habe ich gelegentlich im Aufnahmen-Menue, nirgends sonst. Da hattest Du auch schon irgendwo Patches, ich habe allerdings den Ueberblick verloren.
Alle Patche die ich hatte, müssten eigentlich im aktuellen git drin sein.
Die einzigen Verzögerungen, die ich momentan hier sehe, entstehen durch das Laden der Zusatzinformationen.
Stell doch mal für das Aufnahmenverzeichnis die Menü-Breite auf schmal und das Video auf Fenster. Dann müssten die Verzögerungen deutlich geringer sein.
Grüße
kamel5
-
Hallo Karl,
hier ist das Verhalten mit der FF HD 6400 immer noch zu sehen... (aktuelles git).Gruß
Uwe
-
Hi,
hmm, was auch noch fehlt is die korrekte Anzeige von UHD/2160p Sendern, ich glaube bei skindesigner ist das jetzt auch drin.
CU
9000h
-
Ich hatte inzwischen vdr-2.4.5 installiert gehabt, aber ich habe nun auf vdr-2.4.6 hochgezogen.
Wie du schon angemerkt hattest, ist das Problem (Detailinfo in dem Aufnahmemenu) behoben.
Vielen Dank, Karl!
-
hmm, was auch noch fehlt is die korrekte Anzeige von UHD/2160p Sendern, ich glaube bei skindesigner ist das jetzt auch drin.
Wenn mir jemand passende Icons bastelt, wäre das sicher kein Problem und ginge recht schnell. Ansonsten dauert es etwas länger.
Gruß
kamel5
-
Ich habe im letzten commit jetzt mal alle aus meiner Sicht unnötigen Flush()-Aufrufe auskommentiert, das sollte schon einiges Verbessern.
Wie schon vorher geschrieben, solche Hacks hatte ich auch schon bei mir, aber eine saubere Loesung ist das aber nicht.
Damit scheint es jetzt so zu sein, dass erstmal eine "leere" EPG-Deteilansicht erscheint, dann aber der ganze Text auf einmal. Ja, ist vom Gefühl angenehmer als vorher, aber vor den Aenderung mit den Tabs fuer die normale Info und Wiederholungen war es noch besser. Auch ist der Strich zwischen dem Titel- und Textbereich verloren gegangen, gefiel mir vorher besser, aber ueber Design kann man streiten...
Die einzigen Verzögerungen, die ich momentan hier sehe, entstehen durch das Laden der Zusatzinformationen.
Stell doch mal für das Aufnahmenverzeichnis die Menü-Breite auf schmal und das Video auf Fenster. Dann müssten die Verzögerungen deutlich geringer sein.
Ich bin auch hier weniger an Hacks interessiert, mehr an Verstaendnis des Problems und einer eventuellen sauberen Loesung.
Was genau fuer Zusatzinformationen sind das, wo kommen die her, welche Patches fuer was (vdr core, plugins,...?) braucht man da?
Das schmale Aufzeichnungsmenue finde ich haesslich und schlecht lesbar, aber weniger Informationen werden da doch auch nicht angezeigt. Wieso macht das einen Unterschied? Testen laesst sich die Verzoegerung bei mir schlecht, meistens geht es verzoegerungsfrei, aber selten dauert die Anzeige des Aufzeichungsmenue so ca. 5 Sekunden. Da denkt man, man hat die Fernbedienung nicht richtig gedrueckt, dann springt man aber gleich drei Menues weiter.
Gruss,
S:oren
