Jetzt bewegt sichs auch noch (neu Version 0.4.5)

Moin,

ich habe mal ein neues Feature eingebaut...mal schauen wie es so ankommt

Jedes ViewElement, dass man "detachen" kann (Erklärung siehe hier), kann man nun statt einer fadetime auch die Attribute shifttime, startx und starty mitgeben. startx und starty geben die Startkoordinaten für das ViewElement an, "shifttime" ist die Zeit in Millisekunden, in der das ViewElement dann von der Startposition zu der entgültigen Position bewegt wird. Die entgültige Position ist die Position, die in den jeweiligen Areas des ViewElements definiert ist.

Ich habe das Featuire mal im metrixHD in displaychannel und displaymenu zur Demonstration eingebaut. Im displaychannel bewegen sich Zeit und Wetter von rechts in den Bildschirm, im Hauptmenu "fliegen" die Timer rein

Da das FadeIn bei einigen wohl auch nicht so wirklich performant läuft, würde mich mal interessieren, wie der Effekt bei euch so rüberkommt...also bitte mal testen und Feedback geben.

Ciao Louis

Zitat von vectra130

Könntest du ein "Universal" Viewelement dabei packen das man detachen kann? Ich hätte da so ne Idee und brauche dazu ein separates detach-bares Element

Nimm halt <customtokens>...wenn es Sinn macht, kann ich solch ein ViewElement immer noch einbauen.

Ciao Louis

Nein.

Moin,

Zitat von maz

Die Bewegung des jeweiligen Objekts ist geradlinig-gleichförmig (v=konst.) oder?

genau, ich bewege einfach die obere linke Ecke des Rechtecks mit konstanter Geschwindigkeit vom Startpunkt zum Endpunkt.

Zitat von maz

Bei meinem Samsung-TV sieht man z.B. dass die Bewegung nach dem Einfliegen kurz vor Erreichen der "Endposition" noch abgebremst wird.

Die lineare Funktion zur Berechnung könnte man sicherlich auch noch alternativ mit einer anderen ersetzen. Ich könnte ja noch einen Parameter "shiftmode" einführen, den könnte man dann von "linear" auf sonstwas umstellen. Müssten sich man mal überlegen, was da sinnvoll ist.

Bevor ich dieses Feature weiter ausbaue, möchte ich erst mal auf Feedback warten, wie das auf den verschiedenen Hardwarekonstellationen so läuft. Ich muss sagen, ich war positiv überrascht, ich hätte gedacht, das "ruckelt" mehr. Auf meiner Entwicklungskiste läuft es aber erstaunlich "smooth".

Ciao Louis

Zitat von seahawk1986

es sieht in der Kanalinfo nur etwas komisch aus, wenn die Uhrzeit und die Wetter-Infos zeitlich knapp versetzt einfliegen - könnte man eventuell Gruppen definieren, die dann zusammen einfliegen, wenn die Elemente so weit sind?

Danke für das Feedback.

Hm, jedes Viewelement läuft in einem eigenen Thread. Da ist es natürlich in gewissen Maße Zufall, wann welcher Thread CPU Zeit bekommt, das kann ich nicht so wirklich beeinflussen. Ich muss das aber in getrennten Threads laufen lassen, ansonsten wäre man zu unflexibel. Es wäre ja z.B. auch möglich, die Uhrzeit von oben und das Wetter von rechts mit verschiedenen Geschwindigkeiten einfliegen zu lassen.

Über Gruppen von Viewelementen, die das gleiche "Einfliegverhalten" haben, könnte ich mal nachdenken...würde aber nicht ganz zum aktuellen Konzept passen.

Ciao Louis

Moin,

ich bin positiv überrascht, dass das neue Animation Feature anscheinend bei allen, die es bisher getestet haben, und auch auf schwächerer HW rund läuft. Ich hätte das nach den durchwachsenen Erfahrungen mit dem Fading nicht erwartet. Das war auch der Grund, warum ich das nie implementiert habe

Deshalb habe ich mich entschlossen, noch mutiger zu werden und das ganze noch auszubauen Aktuell lassen sich ja nur einzelne Viewelemente animieren. Ich denke aber, dass es insbesondere bei den "kleineren" Views (also allen ausser dem VDR Menü) auch schick sein würde, den ganzen View "einfliegen" zu lassen. Also z.B. beim Umschalten analog zum Fading den ganzen displaychannel view z.B. von unten in das OSD hinein zu bewegen. Des weiteren möchte ich den Skindesigner so umbauen, dass alle Viewelemente "detachbar" sind. Aktuell sind das ja nur bei bestimmten Viewelementen möglich. Das liegt an der aktuellen Implementierung, die noch ein wenig umständlich ist.

Weiterhin gefällt mir an der aktuellen Implementierung auch noch nicht, dass es für die Animation einen fixen Startpunkt für alle Areas eines Viewelements gibt. Sind alle Areas genau gleich positioniert (gleiche Koordinaten und gleiche Größe), dann ist das kein Problem, sind jedoch die Areas unterschiedlich positioniert, schaut das irgendwie seltsam aus. Den Effekt kann man im metrixHD bei den Timern im Hauptmenü erkennen. Die Timer starten alle am gleichen Startpunkt und "fliegen" dann auf ihre jeweilige Endposition. Irgendwie ist das ja auch ein witziger Effekt, aber meistens will man das wohl anders. Ich werde deshalb zusätzlich zur Definition eines festen Startpunkts die Möglichkeit anbieten, Viewelemente von unten und oben vertikal und von links und rechts horizontal einfliegen zu lassen, auch wenn die einzelnen Areas unterschiedlich positioniert sind.

Wie geschrieben, ich muss dazu erst mal einiges im Skindesigner umbauen und optimieren, kann also ein bisschen dauern. Zumindest wissen die, die es interessiert, schonmal bescheid, was hier noch so kommt. Die Feature Requests wären wohl eh gekommen, sobald das jemand in seinem Skin einbauen will

Ciao Louis

Zitat von vectra130

Im Bugtracker hat dir jemand geschrieben das die Blinkenden Elemente beim Faden nicht berücksichtigt werden. Dies betrifft auch die neue Shift Funktion.

Danke für den Hinweis....wenn ich das eh umbaue, kann ich das gleich mit fixen.

Ciao Louis