[ANNOUNCE] Text2Skin 1.0 final

Zitat

Original von salaam
Dann hat der gcc den Fehler also "wegoptimiert". Auch gut.

Cool ... jetzt noch nen diff und wir sind schlauer

LG
Roman

(SCNR)

Zitat

Original von gromit
[QUOTE]

Kann das nicht zu Problemen mit glibc führen ?

Nein normalerweise nicht. Die aktuellen gcc Versionen sind sehr fortschrittlich wenn es ums kompilieren geht.

Schau mal hier ne tolle Anleitung.

Imsadi

Komisch ohne Änderung lief es auf meinem gcc (GCC) 3.4.3
noch nich schneller. Habe allerdings zu meiner Schande immer noch
nich die -O3 Option probiert. Ich werde mich aber heute abend endlich mal dran setzen und berichten.

Gruss,

Jörg

Hi!

Kann hier leider keine merkliche Verbesserung nachvollziehen.

Gruß,
Brougs78

So ich habe das mal getetest und siehe da, bei mir auch keine Änderung und ich habe einen schnellen Prozessor. Aber was mir aufgefallen ist.
Jeder Sprung von einem Menüpunkt auf den anderen hatten einen etwa 2-3 sekündigen Festplattenzugriff zur Folge. Ich weiss nich was da passiert aber mit DeepBlue kann ich dieses Verhalten nicht nachvollziehen. Also scheint irgendwie das was mit den Icons zu tun zu haben die da nachgeladen werden (sollte ja angeblich nur beim Programmstart bzw. Skinwechsel geschehn) ? Evtl. kann man hier eine Cache Funktion ein und ausschalten ?

Ich bin echt ratlos.

Gruss,

der ratlose Jörg

So habe mal einfach ins log geschaut und folgende Meldung gefunden.

Feb 26 12:24:04 chaplin vdr[2280]: ERROR: Font file (/video/plugins/text2skin/Enigma/tahoma.ttf) could be opened or read, or simply it is broken
Feb 26 12:24:04 chaplin vdr[2280]: ERROR: Text2Skin: Couldn't load font tahoma.ttf:22

Also mal flugs den link richtig gesetzt freetype installiert und siehe da es läuft.
Jetz nur ne doofe Frage wenn ich im Makefile von text2skin angebe ohne Freetype warum interessiert es dann das Skin nich ?

Hmm schon komisch. Aber egal mein Problem ist auch gelöst und ich kann nur sagen jetz bin auch ich begesitert. Ist minimal langsamer wie DeepBlue aber dafür auch schöner (Ok anders)

Gruss,

Jörg

P.S. : Kann man die Grösse der OSD Fenster und schriften noch verkleinern ? Evtl über Konf eintrag ? Naja muss mich jetz mal intensiv damit beschäftigen-

LordJaxom:

Zitat

Über Conditions kann der Text verschoben werden, ...

Wie geht das? Ich probiere gerade in einem Skin den EPG-ShortText hinter dem EPG-Title anzuzeigen, allerdings will ich unterschiedliche Fonts benutzen.

So wird für beides der gleiche Font benutzt:

<text x1="98" x2="595" y1="-139" y2="-112" color="DB_Green" font="Osd">{PresentTitle} {PresentShortText}</text>

Ein Würgaround wenigstens für die Farbe ist, wenn ich anschliessend noch mal den Title in der anderen Farbe ausgebe:

<text x1="98" x2="595" y1="-139" y2="-112" color="DB_Green" font="Osd">{PresentTitle} {PresentShortText}</text>
<text x1="98" x2="595" y1="-139" y2="-112" color="DB_TextLight" font="Osd">{PresentTitle}</text>

Aber ich kann leider nicht auf zB. font="Sml" wechseln oder zum Beispiel hinter dem fixen "text" title einen marquee für den ShortText benutzen.

Gibt es eine allgemeine Möglichkeit zur relativen Positionierung hinter/unter dem vorherigen Element?

Danke,
Marcus

Hallo,

Zitat

Original von brst
hier mal meine Erfahrung zu einem CPU Last Problem, dass ich beim graphtft Plugin hatte.
Ich habe vor kurzem einen Patch erstellt, der das graphtft Plugin zum Scrollen der Sendungstitel bringt, sobald diese länger sind als die Breite des TFT's - wie beim T2S Plugin im Setupbereich.

Leider musste ich feststellen, das die CPU Last auf meinem System bei Normal TV ohne graphtft patch bei ca 0,6 - 0,9% lag, mit dem Patch zwischen 40 und 50%.
Nachdem ich ein wenig geforscht habe war es klar, dass es an den Intervallen lag, die die Häufigkeit der Aktualisierung des TFT's angeben. Ohne Patch refresht das Plugin alle 60 Sekunden im Bereich Normal TV. Mit der ersten Variante des Patches wurde der Interval grundsätzlich auf die im Setup hinterlegte Millisekudnen Anzahl herunter gesetzt.

Das war das Problem.

Nachdem ich das Programm so verändert habe, dass der Millisekundenintervall nur für die Zeit des Scrollens eingestelt wird, ist zumindest bei mir alles bestens. Für die Zeit des Scrollens steigt die CPU Last, danach kehrt wieder Ruhe ein.

Ich habe allerdings keine Ahnung, ob das text2skin Plugin ähnlich funzt. Aber vielleicht hat ja jemand anderes noch weitere Ideen.

Alles anzeigen

Die -g und -O3 optimierung hat bei mir nichts gebracht der sprung von ImageMagic 6.0.2 zu 6.1.9 war aber spürbar ...
Nur leider ist es immer noch nicht so richtig gut !?

Ich denke mal das Stefan hier an was richitiges dran ist !

ich nutze master-timer für die erstellung der timer und so gut wie alle timer landen in unterverzeichnisse - sprich sind so lang das überall gescrollt wird.

Wenn ich auf einen timer eintrag stehe wo nicht gescrollt wird ist die CPU lausladsstung OK (5%), gehe ich aber auf einen der scrollt habe ich gleich 60-80% !!

Gehe ich wieder zurück ist die auslastung wieder niedrig (5%) !

Bei mir werden etliche timer (6-9) übersprungen wenn ich die "nach unten" taste drücke !

Suse 9.1
Gcc 3.3.3
PIII 933
Text2skin 1.0
Enigma 0.2 mit dem letzten Enigma.skin was im Enigma 0.2 thread enthalten ist.

Einige timer-beispiele :
Kinder~_New~Barney~Am schönsten ist es Zuhause
Kinder~_New~Jim Hensons Der Bär im großen blauen Haus~Alles verbunden

Gruß
Viking

Zitat

Wenn ich auf einen timer eintrag stehe wo nicht gescrollt wird ist die CPU lausladsstung OK (5%), gehe ich aber auf einen der scrollt habe ich gleich 60-80% !!

Genau dieses Problem hatte ich auch (siehe oben). Allerdings benutze ich keinen Autotimer. Bei mir trat dieses Phenomen immer auf, sobald etwas gescrollt wird.

Allerdings half bei mir die Optimierung mit -02

Irgendwas stimmt da am Code nicht, ich bin aber leider kein Coder

Tilo

Zitat

Original von salaam

Allerdings half bei mir die Optimierung mit -02

hast du da eine Null oder ein grosses O (wie in Opa)?

wenn du eine Null hast, ist bei dir die Optimierung komplett abgeschaltet und _das_ ist es was bei dir geholfen hat.

Zitat

Wenn ich auf einen timer eintrag stehe wo nicht gescrollt wird ist die CPU lausladsstung OK (5%), gehe ich aber auf einen der scrollt habe ich gleich 60-80% !!

Für einen Test habe ich mal alle horizonalen marquee Scrolltexte aus Enigma-0.2 durch text definition ersetzt.
Leider brachte dies keinen Erfolg, das hoch- runterscrollen im Menü geht dadurch nicht flüssiger, sondern bleibt subjektiv gleich.
Fonts habe ich ebenfalls mal ausgetauscht, daran liegt es auch nicht.

...ich befürchte langsam, dass man nur mit genaueren Kenntissen des text2skin-Codings hier weiterkommt

Habt Ihr die -O3 Optinmierung eigendlich nur im text2skin plugin eingeschaltet oder in der make.conf des vdr und alles (inkl. vdr) auf -O3 kompiliert ?

Gruß,
Gromit

Zitat

hast du da eine Null oder ein grosses O (wie in Opa)?

Hast recht. Es ist der Buchstabe o, KEINE 0

Zitat

Für einen Test habe ich mal alle horizonalen marquee Scrolltexte aus Enigma-0.2 durch text definition ersetzt.
Leider brachte dies keinen Erfolg, das hoch- runterscrollen im Menü geht dadurch nicht flüssiger, sondern bleibt subjektiv gleich.
Fonts habe ich ebenfalls mal ausgetauscht, daran liegt es auch nicht.

Ich hätte auch nicht erwartet dass das was bringt. Ich habe das nur geschrieben, weil man da die hohe CPU Auslastung gut sehen kann.

Tilo

Hi gromit,

Zitat

Original von gromit
[...]

Habt Ihr die -O3 Optinmierung eigendlich nur im text2skin plugin eingeschaltet oder in der make.conf des vdr und alles (inkl. vdr) auf -O3 kompiliert ?

Gruß,
Gromit

Nur im Makefile vom text2skin Plugin.

Gruß,
Marcus

Hallo Lord,

OK, das klingt nicht so gut

Ist das auch der grund für die hohe CPU auslastung beim scrolltext ?
Kann man da nicht was tun ?

Und warum werden zeilen beim "nach unten" gehen mit gedrückter "down" taste übersprungen ?

Wie wäre es wenn du mal eine version 1.0 ohne Double-buffer an einige ausgewählten tester sendest - mal schauen was passiert ?

Ich habe heute noch mal enie vdr 1.3.17 mit t2s 0.8.x + Elchi skin aktiviert und ich kann nur sagen - was für einen unterschied ...
Die zeilen werden wieder einzelnd gezeichnet beim scrollen und alles schnell.

Werde auch mal ohne -g aber mit -O2 statt -O3 probieren.
EDIT: -O2 ist nicht besser als -O3, es ist auf dem ersten blick was CPU auslastung angeht egal

Es kann doch nicht sein das der 3.3.3 compiler schuld ist, oder .... das würde dann doch auch andere programme betreffen !?

Gruß
Viking

Hi LordJaxom,

Zitat

Ich behaupte mal die schlimmsten Bremsen sind der
komplette Neuaufbau des Bildes und das
anschliessende Vergleichen des neuen Bildes mit
dem "Double-Buffer", um die Datenmenge die zur DVB
übertragen wird gering zu halten.

Alles anzeigen

Wo genau im Coding (Datei/Funktionen) steht das denn ? (Mal so interessehalber

Zitat

Leider ist mir nicht eingefallen, wie man vor dem
Zeichnen sinnvoll feststellen kann welche Bereiche
sich verändern (werden). Beim C++-Coding eines
Skins kann man darauf im Design direkt Rücksicht
nehmen, hier geht das nicht, da ich ja das Design
des Skin-Designers beim Proggen noch nicht kenne.
Da Skins auch Animationen enthalten können, müsste
hier eine Vorausberechnung für jedes Bild geben,
um zu ermitteln welche Stellen sich ändern würden.

Alles anzeigen

Grundsätzlich muß es da aber schon eine Möglichkeit geben.
Wenn text2skin nicht weiß welche Bereiche beim Scrollen verändert werden,
so könnte der Skin Ersteller im Skin selber die Bereiche definieren bzw.
die Objekte die beim Scrollen verändert werden (i.d.R. nur der Scrollbalken
im Scrollbereich und evl. ein Image).
Diese Definitionen kann text2skin dann auslesen und beim Scrollen berücksichtigen.

Zitat

Möglicherweise würde das deaktivieren des
Double-Bufferings einen Geschwindigkeitsvorteil
bei der Berechnung ergeben, aber dann wird die
DVB-Karte wieder zum Flaschenhals (der sie ja so
schon ist).

Alles anzeigen

Hier bin ich auch dafür einmal das Double-Bufferings
zu deaktivieren und einige Tests zu machen.

Zitat

Ein Königreich für RLE-Kompression

Wer hat denn Zugriff auf die Firmware und die Kenntisse diese
RLE Kompression dort einzubauen ?

text2skin ist wirklich klasse, aber die Performanceprobleme
vermiesen einem echt den Spass bei gut aussehenden Skins

Gruß,
Gromit

Hi LordJaxom,

Zitat

Naja die Routinen in render.c (Update() im eigenen
Thread) malen zunächst in Bitmaps (screen.c) und
beim Flush werden die Bitmaps ins OSD gezeichnet
(dort sind es auch zunächst Bitmaps, das ist
sozusagen der Doublebuffer). Dabei findet in VDR's
osd.c der Vergleich statt (DrawPixel bzw.
SetIndex).

Alles anzeigen

Danke für die Erklärung, so ists leichter das ganze zu verstehen

Zitat

Die Malfunktionen in screen.c direkt aufs OSD zu
leiten sollte kein Problem sein, ist sogar
größtenteils schon vorbereitet (#define
DIRECTBLIT).

Das
#ifndef DIRECTBLIT
bzw. dessen else Zweig
kapselt die mOsd->....
Aufrufe wie ich gesehen habe.

Meinst Du mit "größtenteils", dass da noch #ifndef DIRECTBLIT's fehlen ?
Da ich mich nicht so auskenne in Deinem Coding konnte ich
keine weiteren Stellen finden, was aber nichts bedeuten mag

In der screen.h steht ein
#undef DIRECTBLIT
drin, das muß dann wohl in ein
#define DIRECTBLIT
geändert werden um das Coding zu aktivieren.
Wars das schon ?

(Sorry für den Tippfehler!)

Falls ja und keine Vorschläge für weiter #ifndef DIRECTBLIT's
kommen werde ich das mal heute abend ausprobieren.

Zitat

Die Kompression wollte Klaus wohl irgendwann mal
bauen, allerdings hat er wohl vorher noch einiges
anderes auf der Liste.

Dann befürchte ich das das nochwas dauert, schade.
Ich denke Klaus benutzt keine "langsamen" Skins mit
text2skin, sonst würde dieser Punkt deutlich nach oben
schnellen in seiner ToDo-Liste.

Zitat

Die Bildberechnung an sich kann man sicher auch
noch etwas optimieren, speziell dazu sind mir
einige gute Gedanken gekommen, mal schauen wie und
wie bald ich die umsetzen kann.

Ich bin gespannt und hoffe es bringt spürbar etwas...

Gruß,
Gromit

Hallo,

das reicht leider nicht den #undef DIRECTBLIT
in ein #def DIRECTBLIT zu ändern. habs gestern abend ausprobiert, Text2skin compiliert dann nicht mehr ...

Gruß
viking

Zitat

Original von viking
Hallo,

das reicht leider nicht den #undef DIRECTBLIT
in ein #def DIRECTBLIT zu ändern.

also wenn, dann #define und nicht #def

Hallo,

ja klar, hatte mich vertaen

-#undef DIRECTBLIT
+#define DIRECTBLIT

Gruß
Viking