Posts by S:oren

Quote from kamel5

Das Grundprinzip ist hier so und dafür gibt es im Moment auch die Themenverzeichnisse, das man sich selbst Logos mit Hintergrund macht (dafür gibt es auch ein script im Ordner logoconverter). Diese Logos werden dann bevorzugt benutzt. Ich habe mir, um das zu Testen, mal ein Set für das Theme Green gemacht. Normalerweise ist das dann so, das dieses konvertierte Logo genau an der gleichen Stelle wie das Hintergrundlogo gezeichnet wird. Und wenn dann kein konvertiertes Logo gefunden wird, wird erst im zentralen Ordner nachgesehen oder es gibt gar keins.

OK, das logoconverter-Skript kannte ich nicht. Was soll es denn fuer einen Vorteil haben, den Hintergrund vorab in die Logos hineinzukonvertieren? Performance?

Habs nicht gemessen, aber bringt sicher nicht mehr als wenige Prozent, wenn ueberhaupt. Oder was ist der Sinn, mehr Flexibilitaet?

Quote from kamel5

Für diese 2 letzten Fälle ist das eingeschaltete Hintergrundlogo da. Dann kommt da, wo es kein konvertiertes Logo gibt, das Hintergrundlogo zum Vorschein. Und das sitzt jetzt nicht mehr an der gleichen Stelle wie das mit 100% skalierte konvertierte Logo.

Das ist in meinem Anwendungsfall komplett anders. Der Logohintergrund gehoert fuer mich eher zum Fensterhintergrund von der Geometrie, zum Logo von der Farbe (inkl. Transparenz). Somit ja, der ganze Sinn fuer mich war, dass der Hintergrund nicht mehr an der komplett gleichen Stelle wie das Logo selber sitzt.

Der Hintergrund nutzt die maximale Flaeche aus, so wie vom Designer vorgegeben. Das Logo ist ggf. entweder in x oder y-Richtung etwas kleiner, damit es nicht verzerrt skaliert wird. Oder in beiden Richtungen kleiner wenn es zu klein gespeichert ist, weil es offenbar beim Skalieren nicht vergrößert werden kann (was ja auch wenig Sinn ergibt).

Es gibt also kein Problem, wenn der Logo-Hintergrund ausgeschaltet und ggf. in das Logo selbst einkompiliert ist.

Es gibt auch kein Problem, wenn der Logo-Hintergrund eingeschaltet und nicht in das Logo selbst einkompiliert ist.

Es passt nicht, wenn der Logo-Hintergrund eingeschaltet und zusaetzlich in das Logo selbst einkompiliert ist. Ist dieser Fall an sich nicht sinnlos? Durch die doppelte Anwendung des Logo-Hintergrunds muesste doch zumindest die Transparenz immer zu klein sein!? Und auch bei dem Green-Theme, wenn man kein passendes Logo mit Hintergrund findet, warum sollte man dann unbedingt den leeren Rahmen dazu darstellen?

Mit anderen Worten: Ist der kaputte Fall wirklich relevant? Kann man nicht alle sinnvollen Faelle mit den ersten beiden Optionen abbilden?

Ansonsten waere vielleicht denkbar, den Logohintergrund (optional?) statt des nicht vorhandenen Logos zu laden, wenn ansonsten der Logohintergrund ausgeschaltet ist.

Quote from kamel5

Beim Default-Theme scheint das Alles etwas unproblematischer zu sein, bei z.B. Green sieht man das aber deutlich.

Hast Du fuer das Default-Theme auch konvertierte Logos inklusive Hintergrund? Dann muesste man auch einen Schatten sehen.

Quote from kamel5

Ja, man sieht es z.B. bei einem Ordner im Recordingsmenü bei schmalem Menü.

Ich nutze da das breite Menue. Kann ich mir bei Gelegenheit aber auch mal ansehen, wenn gewuenscht. (Bitte erinnern, wenn ich es vergesse.)

Quote from kamel5

Ich möchte das Ganze ja verstehen und nachvollziehen. Wahrscheinlich werden die Unterschiedlichen Theme-Arten doch verschieden behandelt.

Ich muss mal schauen, wie da die genauen Zusammenhänge sind...

Ich sehe das bei mir so nicht. Kannst Du die Werte channelWidth, channelHeight sowie X, Y, Width, Height von channelLogo und ggf. channelLogoBg posten, von den beiden Faellen (alt und neu, ohne Zusatzpatch von Dir), um zu sehen, was da nicht aligned ist!? Ohne meinen Patch kann sich da alles verschieben je nach Einstellungen.

Danke,

S:oren

Quote from kamel5

Es ist genau anders herum. Zuerst wird in den themenspezifischen Pfaden gesucht und dann erst im zentralen Pfad. Mein Log-Auszug war da etwas missverständlich.

OK, hatte nur da geschaut.

Ich habe die Meldungen abgeschaltet. Da das nur beim Reload des Imagecache gelesen wird, ist das bei mir auch kein Performance-Problem. Habe die Preload-Anzahl im Imagecache auf die Kanalanzahl meiner channels.conf angepasst.

Quote from kamel5

Genau das ist das Problem. Und es hat auch nichts mit meinen spezifischen Einstellungen zu tun.

Im Setup kann man ja einstellen, ob man einen Hintergrund für die Kanallogos haben möchte: "Hintergrund für Kanallogos benutzen: Ja/Nein"

Und genau dieser Kanallogohintergrund passt jetzt, auch mit Deiner letzten Änderung, nicht mehr.

Bei mir ist der Hintergrund einmal da, wenn ich ihn einschalte, gar nicht, wenn ich ihn ausschalte. Entweder hast Du den Hintergrund in Deine Logos einkodiert, oder Du hast andere Theme-Images mit dem Logohintergrund in dem Fensterhintergrund. Muss man die separat installieren? Dann habe ich vielleicht alte Versionen, wo es noch stimmte.

Quote from kamel5

Ich verstehe Deine Beweggründe schon, ich habe auch so einen Monitor. Dafür kannst Du doch aber im VDR-OSD-Setup die Werte Links, Oben Breite und Höhe ändern.

Ja, selbstverstaendlich habe ich das gemacht. Nur kann ich dann auf meinem 1280x720-OSD keine Channelview-Breite von 1250 mehr einstellen, wie es vom Designer vorgesehen war. Und deshalb will ich den selben optischen Eindruck mit schmalerem Fenster haben, ohne dass sich das Logo verschiebt.

Quote from kamel5

Ja, das ist nicht schön und mir auch schon aufgefallen. Und da gibt es auch noch andere Stellen im Skin.

Dann muss das dort auch gefixt werden.

Quote from kamel5

Meine Zielvorstellungen hier waren deshalb, das man nur eine einzige Logo-Pixmap hat, die entsprechend positioniert wird. Und da hinein wird erst der schaltbare themenspzifische Hintergrund geladen, dann möglicherweise eine konfigurierbare Transparenz und zum Schluss das eigentliche Kanallogo (entsprechend skaliert).

Nur dass das technisch leider nicht geht. Laden kann man nur Bitmaps. Ueberblenden mit der jeweiligen Transparenz kann man nur Pixmaps auf verschiedenen Layern. Man koennte vielleicht teilueberblendete vorgerenderte Pixmaps statt der skalierten geladenen Bitmaps in den imagecache legen, aber das ergibt vermutlich einen anderen optischen Eindruck und man muesste das Redering nochmal selbst implemtieren, was sonst das OSD schon macht. Auch performancemäßig bringt das nicht viel, weil das Logo relativ klein ist und der Datentransfer auf die Karte die Renderzeit uebersteigt.

Quote from kamel5

Und das verbunden mit einem zentralen Logoverzeichnis.

Wenig flexibel. Zumindest bei dem Green-Theme scheint es Absicht zu sein, das Logo selbst nach unten verschoben in den 'Röhrenschirm' des Logohintergrunds einzubetten. Das erfordert wiederum angepasste Logos, wenn man nicht stumpf nur alle Logos verkleinern will (was ja jetzt mit Deinem neuen Setting geht).

Gruss,

S:oren

Quote from kamel5

Braucht es hier wirklich separate Themen-Logos? Die müssen bei jeder Logoänderung auch jedes mal neu erstellt werden. Wer macht das schon. Und dann wundert man sich, warum ein Logo mal wieder anders aussieht.

Würde es hier nicht reichen, wenn es ein Themenspezifisches Hintergrundlogo und zentrale transparente Channellogos gibt. Man könnte dann auch noch beim Aufruf eine variable Transparenz hinzufügen. Oder habe ich da grundsätzlich was übersehen.

Themenspezifisches Hintergrundlogo und zentrale transparente Channellogos sollten reichen. Aber wenn es zentrale Logos gibt, wird doch gar nicht weiter nach Themen-Logos gesucht. Intuitiv wuerde ich das anders herum erwarten, aber zentrale Logos sind wohl tatsaechlich der ueblichere Fall (so auch bei mir). Also wo ist das Problem?

Gruss,

S:oren

Quote from kamel5

Was soll man aber auch denken, wenn das Ergebnis so aussieht:

-> Logohintergrund passt nicht zu Logo.

Was _man_ denken soll, moechte ich nicht festlegen. Ich denke jedenfalls, dass hier jemand das Prinzip nicht verstanden hat. Der Logohintergrund ist zweimal da, also entweder wurde der Logo-Hintergrund zusaetzlich zur konfigurierten separaten Anzeige mit in das Logo einkodiert, oder in das Fenster-Hintergrundbild. Beides widerspricht dem Layer-Design von skinnopacity, und daran habe ich nichts geaendert.

Sollte der Logohintergrund in das Logo einkodiert sein, als Workaround einfach den zusaetzlichen Logohintergrund abschalten. Sollte der Logohintergrund in den Fensterhintergrund einkodiert sein, dann dort loeschen.

Mag sein, dass es vorher mit exakt Deinen Einstellungen fuer OSD-Größe, Fensterhoehe (eingestellt als % der OSD-Hoehe), Fensterbreite (eingestellt ueber linken und rechten Rand) und der vorhandenen Geometrie der Logos selbst 'zufaellig' gepasst hat. Aber da sich bei dem alten Code der Logohintergrund relativ zum Fensterhintergrund verschoben hat, wenn man irgendeine dieser Einstellungen aendert, war das eben nicht universell nutzbar. Und das aendert mein Patch.

Als Hintergrund, warum mich das alte Verhalten stoert: Bei einem meiner Fernseher laesst sich der Overscan nicht abschalten. Das OSD muss also zwingend in der Breite verkleinert werden, sonst sieht man die Raender nicht. Und wenn man dann die selben Logos benutzt, verschiebt sich die Anzeige, das ist meiner Ansicht nach unbrauchbar. Ebeso aergerlich, dass sich der optische Eindruck je nach eingestellter OSD-Größe aendert. So laesst sich eben nicht ein universelles Theme-Design bauen. Das waere jetzt moeglich, erfordert aber ggf. kleinere Anpassungen an vorhandenen Themes (und auch da eher nicht, wenn man sich an das Layering gehalten hat). Dass zumindest das Default-Theme passt, finde ich logisch (und kommt mir auch zusaetzlich entgegen, weil ich dies nutze).

Gruss,

S:oren

Quote from kamel5

Sehr schön, ich schaue mir das an.

Die Patches von heute ganz frueh waren leider kaputt. Es waren Codeaenderungen fuer beide unabhaengige Sachen vermischt. Hab es jetzt nochmal gepusht, hoffentlich korrekt sortiert.

Gruss,

S:oren

Quote from S:oren

Habe mir die mitgelieferten Fenster- und Logohintergruende des default-Theme nochmal genauer angeschaut. Die haben Größen von 1250x180 bzw. 184x130. Das sieht fuer mich so aus, als wenn das exakte unskalierte Größen fuer ein 1280x720er OSD sein sollen. Werde meine Geometrie exakt darauf anpassen (entsprechend skaliert fuer andere OSD-Aufloesungen oder Randabstaende des Fensters).

Neue Version in den test-Branch eingecheckt. Das sollte also jetzt das 'originale' Design sein.

Und es skaliert ordentlich, wenn man das Fenster schmaler oder hoeher macht, oder die OSD-Aufloesung aendert. Nichts verschiebt sich mehr.

Quote from kamel5

Im Theme Green sieht man, das ohne diese Änderung der Hintergrund nicht mehr passt.

Das macht mich echt traurig. Ich versuche hier, ein konsistentes Design hinzustellen. Und du machst es gleich wieder kaputt, offenbar ohne jegliches Verstaendnis, was die beiden Werte bedeuten und wann sie gleich oder warum verschieden sind.

Quote from kamel5

Die ganze Channellogo Darstellung ist aus meiner Sicht sowieso nicht optimal. Es gibt ja hier den Logohintergrund, dann transparente Logos, konvertierte Logos, themenspezifische Logos und auch mal keine Logos, und das wird beim Laden alles berücksichtigt. Im Endeffekt wäre es wahrscheinlich sinnvoll, hier auch nochmal alles zu überarbeiten. Im Prinzip bräuchte es ja nur einen themenspezifischen Hintergrund und ein transparentes Logo, dann könnte man sich den ganzen Rest sparen.

Sparen koennte man sich bei dem Skin viel, daher ja meine Idee mit der light-Version. Aber ausgerechnet das Design an sich zu aendern, finde ich nicht gut. Man koennte natuerlich den Logohintergrund fest in den Fensterhintergrund integrieren. Dann waere das aber nicht mehr abschaltbar.

Gerade das besondere Design mit exzessiver Konfigurierbarkeit war immer zentrale Eigenschaft von skinnopacity.

Gruss,

S:oren

Quote from S:oren

Die Umrechnung von absolutem zu relativem Abstand gelingt somit nicht universell und ich konnte die Idee des Designers nicht eindeutig erkennen.

Habe mir die mitgelieferten Fenster- und Logohintergruende des default-Theme nochmal genauer angeschaut. Die haben Größen von 1250x180 bzw. 184x130. Das sieht fuer mich so aus, als wenn das exakte unskalierte Größen fuer ein 1280x720er OSD sein sollen. Werde meine Geometrie exakt darauf anpassen (entsprechend skaliert fuer andere OSD-Aufloesungen oder Randabstaende des Fensters).

Quote from kamel5

Diese Änderung hat nur Einfluss auf das Logo selbst, sollte also keinen Einfluss auf den Hintergrund haben.

Da hatte ich auch schon mal dran gedacht, den Hintergrund auch mit zu skalieren, das hatte ich dann aber vertagt.

Das Logo zu skalieren hatte nur den Hintergrund, das es manchmal etwas zu groß erschien, und ich dann die Skalierung als Setup-Parameter genommen habe, damit jeder selbst entscheiden kann, wie groß es sein soll.

OK, das soll also einen Rand um das Logo selbst innerhalb des Logohintergrunds bewirken. Wenn ich mich dunkel erinnere, hatte ich das beim Generieren meiner Logos schon beruecksichtigt mit 5% transparentem Rand.

Jedenfalls ist diese Einstellung unabhaengig von meinen Aenderungen fuer den Logohintergrund.

Quote from kamel5

es werden folgende Unterschiede bei den Themes gemacht: dtFlat, dtBlending und dtGraphical, die als Wert "displayType" übergeben werden.

Das hatte ich schon gesehen, an dieser Stelle aber nichts veraendert.

Quote from kamel5

Ich habe hier bei mir auch noch ein paar zusätzliche Kleinigkeiten gefixt, und habe das gerade mal in meinen devel-Branch hochgeladen.

Das "Also align channel logo" finde ich nicht so gluecklich. Wenn die Werte fuer das Logo nicht stimmen, dann sollten sie im geometrymanager richtig erzeugt werden, denke ich.

Was stimmt da nicht? Irgendwas bei Logo-Größe kleiner 100%?

Vermutlich sinnvoll, wenn ich das in meinem neuen Patch auch gleich richtig mache...

Gruss,

S:oren

Quote from kamel5

Allerdings führen die neu eingeführten Parameter dazu, das es jetzt bei anderen Theme nicht mehr ganz passt (vertical alignment). Ich muss mal sehen, wie ich das kompatibel zu allen Theme machen kann.

Es ist nur ein Parameter "neu", die Breite des Randes um den Logohintergrund (oben, links, unten gleich). Das war vorher eine absolute Zahl in Pixeln (mit Rundungsfehler), und fuehrte deshalb je nach eingestellter OSD-Auflösung und eingestelltem Abstand der Fensterraender zu einem anderen optischen Eindruck. Also an dieser Stelle nicht konsequent, wo man sonst ja eher Prozente der OSD-Maximalgröße hat (oder z.B. relative Anpassungen der Fontgröße).

Die Umrechnung von absolutem zu relativem Abstand gelingt somit nicht universell und ich konnte die Idee des Designers nicht eindeutig erkennen. Offenbar passt mein Empfinden hier nicht. Aber ich habe auch keine Idee, ob das wirklich ueber alle Themes gleichartig implementiert ist.

Nicht ganz sicher bin ich mir, ob Deine kuerzlichen Anpassungen mit der Logogröße in Prozent das nicht noch verschlimmert haben. Kann sein, dass man jetzt lieber die Größe des Hintergrunds statt der Größe des Logos selbst mit Deinem Parameter beieinflussen sollte. Soll ich das mal so anpassen?

Jedenfalls sollte der Skin mit 720er Aufloesung auch gut aussehen, und im Idealfall genau so wie mit 1080er Aufloesung, denke ich.

Gruss,

S:oren

Noch ein Update. Jetzt passt das Logo fuer 720er und fuer 1080er OSD-Aufloesung. Und sieht vom Hintergrund auch identisch aus.

Keine weiteren Updates mehr noetig. Zumindest wenn nicht sonst jemand noch Anmerkungen hat...

Gruss,

S:oren

Hab nochmal ein Update fuer den test-Branch gepusht...

Gruss,

S:oren

Ich habe jetzt mal 2 Fix-Vorschläge gebaut und in meinen Test-Branch gepusht:

https://github.com/s-moch/vdr-…commits/skinnopacity-test

Da sieht erstens der Logohintergrund bei mir gut aus, zweitens ist das Kanalwechsel-Display jetzt deutlich schneller (unter 100ms beim first Flush). Letzteres klappt nur, wenn man keine Poster anzeigen will. Das mache ich aber sowieso nicht.

Wuerde mich freuen, wenn das jemand testet (und vielleicht uebernimmt).

Gruss,

S:oren

Quote from kamel5

Jetzt wo Du das schreibst, es gibt im Setup vom Plugin den Punkt "High Level OSD". Wenn man den aktiviert, funktioniert Truecolor nicht mehr.

Wahrscheinlich ist damit Hardwarerendering gemeint, wurde dann aber nicht mehr umgesetzt.

Ja, "High Level OSD" heißt Hardware-Rendering, und das war vorher da, bevor es TrueColor gab, denke ich. Jedenfalls erfordert TrueColor-Support das Raw-OSD (VDR-Rendering) und die explizite Aktivierung von TrueColor. Nicht sehr uebersichtlich diese Setup-Einstellung, es gibt ja 3 Modi, was so im Setup nicht direkt ersichtlich ist.

Quote from kamel5

Mit einem anderen Ausgabedevice tritt das Problem nicht auf. Dann kann es wohl nicht am VDR selber liegen?

Etwas mehr habe ich herausfinden koennen. Das Software-Rendering achtet genau darauf, welche Teile des OSD sich geaendert haben, nur die werden geupdatet. Deshalb werden beim ersten Flush mehr Daten an die Karte geschickt als danach. Dadurch unterscheiden sich auch die Transferzeiten. Soweit ergibt das fuer mich Sinn. Andere Ausgabedevices haben diese Transferverzoegerung nicht (in dem Ausmaß), deshalb faellt das dort nicht auf.

Nur was der Mutex mit Verzoegerungszeiten zu tun hat, erschließt sich mir nicht. Jedenfalls wenn es nur einen OSD-Thread gibt (sonst waere das klar).

Gruss,

S:oren

Quote from S:oren

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden.

Wenn man etwas laenger hinschaut, sieht man, dass das TrueColor-OSD eigentlich komplett vom VDR intern gerendert wird. Das dvbhddevice nimmt die VDR-gerenderten Pixmaps, konvertiert die ggf. von ARGB8888 in ARGB8565 oder ARGB4444 (je nach Einstellung im Setup), teilt das Ergebnis ggf. auf (weil die Buffer-Maximalgröße fuer einen Treiberaufruf 1MByte betraegt), und schickt das auf die Karte. Das Hardware-Rendering beschraenkt sich dann auf das Zusammenkopieren der Teile.

Quote from kamel5

Ich habe jetzt als aktuelle Lösung ein zusätzliches Lock() Unlock() Paar vor die Animationsschleife gesetzt.

Das LOCK_PIXMAPS ist wirklich nur ein Mutex. Ja, das wird beim Flush im dvbhddevice gelockt. Aber wenn das zu Verzögerungen führt, dass muss ja ein anderer Thread auch gerade ein Lock auf dem Mutex haben. Aber welcher Thread sollte das sein, wenn nur ein einziger Thread sich mit dem OSD befasst?

Gruss,

S:oren

Quote from kamel5

Übrigens habe ich gerade festgestellt, das die Zeit auch vom Farbformat abhängt, bei ARGB4444:

1080: skinnopacity: First Flush(): 336 ms

720: skinnopacity: First Flush(): 150 ms

Schon sehr seltsam.

Bei ARGB4444 gehen ja nur halb so viele Daten ueber den Bus wie bei ARGB8888.

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden. Das hatte ich anders in Erinnerung.

Waere nochmal interessant, ob Software-Rendering bei modernen Mehrkernprozessoren nicht schneller ist. Wenn ich mal viel Zeit habe...

Gruss,

S:oren

Quote from kamel5

Schon seltsam, ich würde es trotzdem aber erst einmal darauf beruhen lassen.

Die OSD-Größe "Folge Auflösung" scheint nicht (immer?) richtig zu funktionieren. Wenn ich die fest auf 1920x1080 stelle, dann sehe ich auch größere Zeiten (~745ms). Dann war das doch nur eine Einstellungssache bei mir, sorry.

Ist das OSD bei Dir schärfer (bunter, hübscher) mit 1080er als mit 720er Auflösung? Ich habe hier an meinem Test-VDR eh nur einen alten Fernseher mit 720er Panel, da sehe ich (bis auf "Geometriebesonderheiten" bei der Darstellung / Logogröße) keinen Unterschied. Ist aber tatsächlich deutlich langsamer.

Gruß,

Sören

Quote from kamel5

Du hattest irgendwo mal geschrieben, das Du ein 720p OSD benutzt, dann wäre das erklärbar, denn es hängt von der OSD Größe ab.

Jetzt mal mit 1080i probiert: 308 bis 325 ms.

Dann wieder mit 720p: 301 bis 331 ms.

Die Größenordnung bleibt.

Gruß,

Sören

Quote from kamel5

Anbei mal ein Patch für die Kanalanzeige, der die Zeit vom ersten Flush misst. Animation dabei global aus.

Bei mir sieht das dann so aus:

Mai 02 14:49:08 vdr[364594]: [364594] skinnopacity: First Flush(): 626 ms

Bei mir

May 2 20:33:33 rockpro64 vdr: [1547] skinnopacity: First Flush(): 331 ms

Diese Drittel-Sekunde (329 - 334 ms in 10 Versuchen) hatte ich bisher als normal und unvermeidbar angesehen - auf einem RockPro64 (arm64) und der S2-6400 hinter einem PCIe-Switch (PCI bridge: ASMedia Technology Inc. Device 1182).

Ob es sich bei den Zeiten lohnt, da bei mir weiter zu suchen?

Gruss,

S:oren

Danke fuer's Fixen.

Quote from kamel5

- Im breiten Aufzeichnungsmenü gibt es ja nur eine Zeile und es werden auch keine Fehler angezeigt, nur das "!".

Ich sollte diese beiden Menüpunkte dann auch nur anzeigen, wenn "Schmales Menü" eingestellt ist.

Oder habe ich da noch was falsch verstanden?

Dann habe ich das falsch verstanden. Ja, es gibt das "!", das ist auch richtig so. In den Details zur Aufnahme stehen dann die Anzahl Fehler, aber das soll vermutlich nicht abschaltbar sein. Da habe ich die beiden Menues vermutlich verwechselt.

Wenn diese Einstellungen nicht angezeigt werden, wenn sie keinen Unterschied ergeben, dann wäre das wahrscheinlich weniger verwirrend.

Quote from kamel5

- Das Kanallogo ist jetzt in der Lage konfigurierbar "Vertikale Ausrichtung" -> unten, mittig, oben.

Wenn Du hier beim Default-Theme "unten" einstellst, sollte sich gegenüber dem alten Branch nichts verändert haben (die Berechnung der Lage ist dann die Selbe).

Ich habe das wie vorher auf "unten" stehen. Der Logohintergrund ist jetzt eine(?) Zeile höher und der Radius von dem Logohintergrund oben-links hat dadurch einen anderen Mittelpunkt wie der Radius der Fensterbegrenzung daneben. Nur oben-links passt es nicht (etwas zu hoch), unten-links passt es , rechts faellt es ggf. nicht auf. Ich hoffe, das ist halbwegs verständlich erklärt. Muss ich sonst selber irgendwann debuggen, haengt vielleicht auch von den eingestellten Raendern usw. ab.

Quote from kamel5

Es geht hier um jedes neue OSD (osd = CreateOsd()), genauer den ersten Flush() .

Da muesste ich jetzt nachschauen, wann man ein CreateOSD aufruft. Jedes Mal, wenn man ein OSD-Fenster oeffnet? Vermutlich schon, weil ja die Größe immer anders ist. Bei meinen Versuchen schien es mir, dass nach dem Senderwechsel der erste Aufruf etwas langsamer ist, aber das kommt vermutlich von der Abfrage von EPG und Timern und hat nichts mit Deinem Problem zu tun.

Quote from kamel5

Diese erste Verzögerungszeit ist außerdem abhängig von der OSD Größe und nicht skinnopacity spezifisch, tritt allerdings nicht bei Nutzung eines anderen Ausgabeplugin auf. Dadurch schließe ich den Core-VDR ursächlich aus, und wenn man davon ausgeht, das auch die TT6400 selbst nicht Ursache ist, bleibt nur noch das dvbhddevice-Plugin übrig.

Das Debuggen des dvbhddevice-Plugin übersteigt aber im Moment meine Möglichkeiten.

Hm, wuerde ich mir schon genauer ansehen, nur habe ich diesen Effekt bei mir nicht. Bei mir gibt es keine "Gedenksekunde", oder ich merke es nicht.

Hast Du irgendwo den Patch zum Anzeigen der Verzoegerung? Am besten bei abgeschaltetem Einblendeffekt und ohne Threads, das kann ich aber sonst auch Einschalten, wo ich jetzt den selben Branch verwende. Vielleicht ist es doch ein Effekt durch die "verbotenen" Thread-OSD-Zugriffe!?

Gruss,

S:oren

Quote from kamel5

nachdem es hier schon länger scheinbar keine akuten Probleme gibt, habe ich den letzten Stand mal zu Version 1.1.10 gemacht.

Vielen Dank fuer die neue Version!

Wie vor fast einem Jahr versprochen (auweia!), bin ich jetzt auf den neuen master-Branch umgestiegen (von 1.0.9 auf 1.1.10).
Sieht insgesamt alles gut aus, soweit ich heute getestet habe.

Folgende Kleinigkeiten sind mir noch aufgefallen:

- typo im Kanalwechsel-Menue-Setup: Schriftgr_ä_ße bei den letzten beiden Eintraegen

- mit breitem Aufzeichnungsmenue scheinen die Einstellungen fuer die Fehleranzeige nicht zu wirken (0 Fehler anzeigen aus, 2./3. Zeile ??)

- Der Kanallogo-Hintergrund im Kanalwechselmenue sitzt bei mir jetzt minimal zu hoch. Das kann doch eigentlich nichts mit der neuen Logogröße zu tun haben!? Eher mit dem anderen Branch?

Diese Sache war noch nicht wirklich geklaert:

Quote from kamel5

Noch was TT6400 spezifisches bzgl. Animation:

Das erste cPixmap::Lock() dauert gegenüber anderen Ausgabewegen unverhältnismäßig lange. Das erschließt sich mir nicht ganz, da an dieser Stelle die Hardware der TT6400 ja noch nicht beteiligt sein sollte. Alle nachfolgenden cPixmap::Lock() sind dann unauffällig. Möglicherweise liegt das am dvbhddevice Plugin.

Hieß das, die erste Ausgabe nach dem Start des VDR, oder nach jedem Kanalwechsel? Gab es da noch eine Idee, an welcher Abfrage von anzuzeigenden Details das liegt?

Gruss,

S:oren

Quote from zillerbaer

VDR schickt aus dem Bitstream Packete an PlayVideo/PlayAudio. Ohne den Bitstream zu Parsen geht das gar nicht!

Du moechtest ueber steinalte PES-Aufnahmen diskutieren? Wirklich?
Relevant ist heute doch eher PlayTsVideo/PlayTsAudio. Und da geht es eben um TS-Pakete als die relevante Granularitaet des Bitstroms.

Quote from zillerbaer

Ich mache keine Stimmung, Ich spreche Probleme an.

Selbstgemachte Probleme? Andere Leute suchen Loesungen. Kein weiterer Kommentar.

S:oren