[...] Morgen soll es eine neue Beta geben ...
Na, da wird sich ja einer freuen, 
BTW: Ich verwende, genau wie Louis auch, ImageMagick 6.8.6.8 und damit gibt es keinerlei Probleme.
skinnOpacity 0.9.0 - nOpacity freestyle
-
louis -
October 25, 2013 at 9:35 PM -
Closed
-
-
S:oren: das das Cache erzeugen bei dir so lange dauert ist schon seltsam...vielleicht kannst du einfach mal ein paar Testausgaben einbauen, wie lange die jeweiligen Aktionen beim Cache laden dauern? Wenn es nicht das laden von der Festplatte ist, müsste es ja das erzeugen und skalieren der Bilder per imagemagick sein...
Der Zeitfresser scheint - wie schon befuerchtet - das buffer.resize in cImageCache::InsertIntoSkinElementCache(eSkinElementType type, int width, int height) zu sein. Vermutlich benutzt das FloatingPoint-Arithmetik, die ist wirklich langsam auf dem Kirkwood.
Der passende Workaround wuerde somit sein, die SkinElements gleich in der passenden Aufloesung zu laden. Koennte man den ImageCache irgendwie wieder abspeichern?BTW, die Build-Methode von skinnopacity ist schon recht "eigenwillig" (Uebersetzen in einem Stueck durch #include von .c-Files statt .h-Files). Dadurch wird das "mal eben schnell" Einbauen von Debugmeldungen auf meinem System schon zum Geduldsspiel...
Gruss,
S:oren -
Moin,
Der Zeitfresser scheint - wie schon befuerchtet - das buffer.resize in cImageCache::InsertIntoSkinElementCache(eSkinElementType type, int width, int height) zu sein. Vermutlich benutzt das FloatingPoint-Arithmetik, die ist wirklich langsam auf dem Kirkwood.
Der passende Workaround wuerde somit sein, die SkinElements gleich in der passenden Aufloesung zu laden. Koennte man den ImageCache irgendwie wieder abspeichern?
Heftig, dass das so lange dauert...solange deine Auflösung und dein Setup gleich bleibt, könntest du die gecachten cImages schon einmalig speichern und dann einfach diese wieder laden. Das ist aktuell allerdings nicht vorgesehen. Aber generell sollte das nicht so kompliziert sein, cImages sind ja einfach 2 dimensionale Arrays aus uint32 Werten...die könnte man ja einfach in eine Datei schreiben. Du kannst das ja mal implementieren wenn du magst
BTW, die Build-Methode von skinnopacity ist schon recht "eigenwillig" (Uebersetzen in einem Stueck durch #include von .c-Files statt .h-Files). Dadurch wird das "mal eben schnell" Einbauen von Debugmeldungen auf meinem System schon zum Geduldsspiel...
Da ich programmiertechnisch nicht aus der C/C++ Ecke komme, habe ich mir das am Anfang meiner Plugin-Programmiererei so abgeschaut. War wohl kein gutes Beispiel, dass ich da benutzt habe...da es funktioniert hat, habe ich das so gelassen, und am Anfang ging es auch schön schnell Mittlerweile ist da natürlich einiges zusammengekommen, deshalb wollte ich das neulich mal umbauen...nachdem es mir dann aber alles um die Ohren gehauen hat mit gefühlten 34862 Compilerfehlern, habe ich es auch schnell wieder gelassen Wie genau müsste ich das denn umbauen, damit jede Klasse in ein eigenes .o File gebaut wird und am Schluss alles zusammen gelinkt wird? Gibt es da irgendwo ein gutes Tutorial? Oder mag es mir mal jemand genau erklären, wie man das "üblicherweise" macht?Ciao Louis
-
Hi,
btw in yavdr 0.5 testing wird im Hauptmenu VDR 2.0.3 und bei Einstellungen VDR 2.0.4 angezeigt, bug or feature?
CU
9000h -
Im Zweifel Feature
-
Hi,
was auch noch auffällig ist das die laufende Sendung als Wiederholungs-Termin im EPG Info angezeigt wird.
CU
9000h -
Hi,
was auch noch auffällig ist das die laufende Sendung als Wiederholungs-Termin im EPG Info angezeigt wird.
CU
9000hIst das nicht eher auf epgsearch-Seite zu suchen?
-
Du kannst das ja mal implementieren wenn du magst
Ich habe schon eine 60h-Woche, irgendwann muss ich ja auch mal schlafen
Ich befuerchte, dass wird bei mir so schnell nichts werden. Das Speichern und Laden ginge sicher schnell, aber wie sorgt man fuer die Konsistenz des Caches? Gut, man koennte bei jedem Speichern der setup.conf auch den Cache mit speichern. Einfacher waere wahrscheinlich sowieso, mit einem externen Konverter gleich einen Satz SkinElements in passender Aufloesung hinzulegen. Vielleicht hat hier ja jemand eine gute Idee (und ein Skript...).Wie genau müsste ich das denn umbauen, damit jede Klasse in ein eigenes .o File gebaut wird und am Schluss alles zusammen gelinkt wird?
Ich bin hier zwar auch kein Experte (ich schreibe C++ auch nur beim Patchen von vdr/plugins), aber ich versuchs mal:Erstens: Makefile anpassen
Diff
Display More--- Makefile.orig 2013-11-04 13:55:55.038611604 +0100 +++ Makefile 2013-11-04 14:26:08.415513332 +0100 @@ -55,8 +55,12 @@ DEFINES += -DPLUGIN_NAME_I18N='"$(PLUGIN LIBS += $(shell pkg-config --libs Magick++) ### The object files (add further files here): - -OBJS = $(PLUGIN).o +OBJS = config.o displaychannel.o displaychannelview.o displaymenu.o +OBJS += displaymenuview.o displaymessage.o displayreplay.o displaytracks.o +OBJS += displayvolume.o fontmanager.o geometrymanager.o helpers.o +OBJS += imagecache.o imageloader.o imagemagickwrapper.o menudetailview.o +OBJS += menuitem.o nopacity.o setup.o textwindow.o timers.o +OBJS += $(PLUGIN).o ### The main target:
Dann alleCode#include irgendwas.cin allen .c-Files entfernen. Das beim make entstehende .dependencies-File darf fuer jedes .o nur die Abhaengigkeit von seinem .c haben, und von beliebig vielen .h. Sind da noch andere Abhaengigkeiten von .c, dann stimmt noch irgendwas nicht.
Nun kommt der aufwendige Teil. Da jedes .c-File nun einzeln uebersetzt wird, muessen auch in jedem File alle Abhaengigkeiten deklariert sein. Normalerweise includet jedes .c dafuer sein .h, zusaetzlich muessen meistens in das .h und/oder .c weitere
Code#include irgendwas.hrein. Hier moeglichst nur die wirklich benoetigten Abhaengigkeiten angeben. Werden in anderen Files implemetierte Objekte schon fuer die Deklaration das aktuellen Ojekts gebraucht, dann kommt das #include anderesObject.h schon in das aktuellesModul.h rein, wenns nur fuer die Implementierung gebraucht wird, dann kann das #include anderesObject.h auch in die aktuellesModul.c.
Das nur mal ganz kurz als Uebersicht. Den Code von skinelchi fand ich immer recht uebersichtlich, taugt vielleicht als Anschauungsobjekt...
Gruss,
S:oren -
Hi..
Hi,btw in yavdr 0.5 testing wird im Hauptmenu VDR 2.0.3 und bei Einstellungen VDR 2.0.4 angezeigt, bug or feature?
CU
9000h
Seit wann ist denn freestyle in testing? -
Seit wann ist denn freestyle in testing?
Ich denke das der von Frodo ppa installiert hat wie ich,das ist bei mir auch so.
ich wollte ja aber nicht meckern aus einfachem Grund wie man in Rheinland sagt"Geschenktem Gaul schaut man doch nicht in maul "
MfG:Veni
-
Hi,
was auch noch auffällig ist das die laufende Sendung als Wiederholungs-Termin im EPG Info angezeigt wird.
CU
9000hHm, das hatte ich eigentlich schon mal eliminiert...sicher dass es nicht die gleiche Sendung auf dem HD- bzw. nicht HD Pendant ist? Genau die laufende Sendung sollte nicht als Wiederholung erscheinen.
Ciao Louis
-
Hi,
btw in yavdr 0.5 testing wird im Hauptmenu VDR 2.0.3 und bei Einstellungen VDR 2.0.4 angezeigt, bug or feature?
CU
9000hDas kommt daher weil das Plugin gegen das VDR DEV 2.0.3 Paket gebaut ist...
Wenn Louis mit den Änderungen durch ist, wird es auch wieder ein aktuelles Paket in den yavdr PPAs geben.
-
Moin,
so...nachdem ich keine nicht-ausgefranzten Kreise hinbekommen habe, habe ich für das recoff / recon Symbol in displaychannel jetzt Quadrate mit abgerundeten Ecken gemacht
Icons sind im Git...PS: ich hab das bzgl. der Wiederholungen eben nochmal gecheckt...die aktuelle laufende Sendung wird nicht als WDH angezeigt.
Ciao Louis
-
Bin auch mal dazu gekommen upzudaten. Das mit dem Hintergrundbild in der Kanalanzeige hinter den Icons ist jetzt schön
Dieselben Icons werden aber in der Wiedergabe verwendet. Hier fehlt das Hintergrundbild (sollte natürlich schmäler sein, ist dort ja nur ein Icon).
Jaja, gibt man jemandem den kleinen Finger usw.
Ich habe gerade einen ultralangen Titel bei meinem Test gehabt. Hierbei fiel mir auf, dass es vielleicht schön wäre, wenn der auch scrollen könnte.Bei dem Icon hinter den Kanälen im Menü bist Du jetzt aber ein bischen über das Ziel hinausgeschossen. Ich fand, dass es beim Freestyle Theme passend sei. Du hast es jetzt aber für alle Themes implementiert.
Ein ähnliches Problem bekommt man mit den Menüicons. Man könnte dies analog über ein Hintergrundbild lösen oder (wie bei der Kanalanzeige) über ein on/off, active/inactive, wie auch immer Du das nennen willst System. Am flexibelsten ist man natürlich mit der Kombination.
Das Wechseln der Themes sorgt für heftige Probleme in den Einstellungsdialogen. Mal flackert alles rum und es wird eigentlich keine Änderung mehr übernommen.
Was passiert eigentlich mit den offenen Punkten aus dem geschlossenen Thread? Hast Du die noch auf Deiner Liste zur 1.0?
-
so...nachdem ich keine nicht-ausgefranzten Kreise hinbekommen habe, habe ich für das recoff / recon Symbol in displaychannel jetzt Quadrate mit abgerundeten Ecken gemacht
Icons sind im Git...Sorry aber Rec wahr schon immer rund, und Stop viereckig.
Mfg Multi
-
Hi Ramirez,
Bin auch mal dazu gekommen upzudaten. Das mit dem Hintergrundbild in der Kanalanzeige hinter den Icons ist jetzt schön
Dieselben Icons werden aber in der Wiedergabe verwendet. Hier fehlt das Hintergrundbild (sollte natürlich schmäler sein, ist dort ja nur ein Icon).
Jaja, gibt man jemandem den kleinen Finger usw.Das kann ich noch einbauen...da nehme ich dann aber für den Hintergrund die gleiche Theme Farbe wie in displaychannel.
Ich habe gerade einen ultralangen Titel bei meinem Test gehabt. Hierbei fiel mir auf, dass es vielleicht schön wäre, wenn der auch scrollen könnte.
Wo genau? Beim Abspielen einer Aufzeichnung? Da könnte man scrollen, die Anzeige bleibt ja, bis man sie wieder wegklickt. Bei displaychannel würde ich nicht scrollen wollen, eher abschneiden, dafür ist die Anzeige nicht lange genug sichtbar.
Bei dem Icon hinter den Kanälen im Menü bist Du jetzt aber ein bischen über das Ziel hinausgeschossen. Ich fand, dass es beim Freestyle Theme passend sei. Du hast es jetzt aber für alle Themes implementiert.
Was genau meinst du? Den abgesetzten Hintergrund hinter den Channellogos in den Listen? Dafür habe ich doch eine eigene neue Themefarbe clrMenuChannelLogoBack eingeführt, wenn die genau so gewählt ist wie der Hintergrund, sieht man davon nix. Oder reden wir jetzt aneinander vorbei?
Das Wechseln der Themes sorgt für heftige Probleme in den Einstellungsdialogen. Mal flackert alles rum und es wird eigentlich keine Änderung mehr übernommen.
Hu? Ist das Reproduzierbar? Ich habe schon des öfteren Themes gewechselt und nichts davon gemerkt. Beschreibe das doch bitte ein bisschen genauer, klingt ja fast schon esotherisch
Was passiert eigentlich mit den offenen Punkten aus dem geschlossenen Thread? Hast Du die noch auf Deiner Liste zur 1.0?
Welche denn? Ist da noch was offen?
Ciao Louis
-
Welche denn? Ist da noch was offen?
Ciao Louis
Muss mal wieder updaten. Hat sich eigentlich schon was geändert bei der Reihenfolge der Ansicht der Film-Cover im Rec-Verzeichnis?
Gruß
Steevee -
Sorry aber Rec wahr schon immer rund, und Stop viereckig.
Mfg Multi
Und war schreibt man schon immer ohne "h" und "Stopp" mit zwei harten b *SCNR*
-
Muss mal wieder updaten. Hat sich eigentlich schon was geändert bei der Reihenfolge der Ansicht der Film-Cover im Rec-Verzeichnis?
Vielleicht?!
-
Und war schreibt man schon immer ohne "h" und "Stopp" mit zwei harten b *SCNR*
Aber letzteres nicht schon immer
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!