Antialiasing

  • Moin,


    da der Skindesigner jetzt ja die mächtige Cairo Lib an Bord hat, habe ich mich mal ein bisschen in Cairo eingelesen...als erstes Ergebnis habe ich die DrawEllipse Funktion vom VDR ersetzt, sodass die Ellipsen nun mit Cairo gezeichnet werden. Der Vorteil davon ist, dass die Ellipsen bzw. Teilellipsen jetzt "antialiased" gezeichnet werden, wodurch die leichten Verpixelungen, die mit der VDR eigenen DrawEllipse Funktion entstanden sind, die eben kein antialiasing kann, weg sind. Im Git befindet sich ein Update...bitte mal testen ;)


    Die Template Funktion <drawellipse> erwartet genau die gleichen Parameter wie bisher und verhält sich auch genau so, bis auf einen wesentlichen Unterschied: Die VDR eigene DrawEllipse Funktion zeichnet wirklich nur die Pixel der Ellipse bzw. der Teilellipse, nicht aber den Rest des mit x, y, width, height definierten Rechtecks. Dadurch kann man z.b. eine abgerundete Ecke quasi "ausstanzen", indem man eine invertierte Ellipse mit der Farbe #00000000, also voll transparent, zeichnet. Das funktioniert nun nicht mehr, da jetzt alle Pixel des definierten Rechtecks gezeichnet werden. Beim Antialiasing gibt es eben nicht nur "zeichnen" und "nicht zeichnen", sondern auch einen semitransparenten Übergang.


    Im Holo Skin habe ich das z.B. gesehen...das ist aber leicht zu fixen, einfach z.B. in displaychannel in Zeile 13 das

    Code
    <drawellipse x="0" y="0" width="{areaheight}*0.05" height="{areaheight}*0.05" color="{clrTransparent}" quadrant="-2"/>


    zu

    Code
    <drawellipse x="0" y="0" width="{areaheight}*0.05" height="{areaheight}*0.05" color="{clrBack}" quadrant="2"/>


    ändern. Das muss natürlich für alle drawellipse gemacht werden, die auf diese Art und Weise eingesetzt werden.


    Mit den Möglichkeiten von Cairo kann man so allerhand anstellen...insbesondere kann man dem Skindesigner weitere native Zeichenfunktionen verpassen ;) Was mir so sinnvollerweise einfällt, wären die folgenden neuen Funktionen:


    - drawarc: Kreisbogen innerhalb eines Rechtecks (quasi die drawellipse Funktion, die nur den Rand der Ellipse zeichnet)
    - drawline: Linie von Punkt x nach Punkt y
    - drawtriangle: gefülltes Dreieck definiert durch drei Punkte x, y, z
    - drawobject: beliebiges Objekt innerhalb eines Rechtecks definiert durch ein Array von Punkten, die miteinander verbunden werden (z.B. ein Stern oder sonstwas), gefüllt oder nur der Rahmen
    - drawstyledrectangle: "gepimptes" Rechteck mit abgerundeten Ecken eines definierbaren Radiuses, mit optionaler Rahmenfarbe, mit Farbverläufen (das kann man mit Cairo ziemlich granular definieren)


    Fällt euch noch mehr sinnvolles ein? Oder ist das schon zu übertrieben?


    Ciao Louis

  • Hi Louis

    als erstes Ergebnis habe ich die DrawEllipse Funktion vom VDR ersetzt, sodass die Ellipsen nun mit Cairo gezeichnet werden.

    Mal ganz doof gefragt: Hebelst du damit nicht die Möglichkeit der GPU-Unterstützung für Ausgabedevices aus?


    Dadurch kann man z.b. eine abgerundete Ecke quasi "ausstanzen", indem man eine invertierte Ellipse mit der Farbe #00000000, also voll transparent, zeichnet. Das funktioniert nun nicht mehr, da jetzt alle Pixel des definierten Rechtecks gezeichnet werden.

    Transparent Pixel sind auch Pixel, die sich zeichnen lassen, oder verstehe ich das falsch? Ich hab da zwar keine Aktien drin, aber das Verhalten der OSD-Elemente zu ändern halte ich für eine schlechte Idee.


    Gruss
    Thomas

  • Im Holo Skin habe ich das z.B. gesehen

    So richtig verstehe ich das im Moment noch nicht. Ob das nicht zu unvorhergesehenen Nebeneffekten führt... Ich schaue es mir gleich mal an.

    Fällt euch noch mehr sinnvolles ein? Oder ist das schon zu übertrieben?

    Ich finde das schon ziemlich toll.


    Man kann zwar vieles Mit SVGs lösen. Aber richtig gut funktioniert sowas nur, wenn man von einem festen Seitenverhältnis ausgeht. Ändert sich dieses werden die sauber abgerundeten Ecken plötzlich in die Länge gezerrt.
    Wenn man das in der SkinDesigner Syntax hat, kann man da etwas besser auf geänderte Seitenverhältnisse reagieren.

  • reufer: ich kenne mich nicht so wirklich aus, wie die GPU Unterstützung für die Ausgabe funktioniert...aber die DrawEllipse Funktion macht ja auch nichts anderes, als die zu zeichnenden Pixel über die CPU zu berechnen und dann Pixel für Pixel auf eine Pixmap zu zeichnen. Ich erstelle nun mit Cairo ein Image und übertrage die einzelnen Pixel dieses Images auf die Pixmap. Aus meinem Verständnis sollte das für die GPU Unterstützung irrelevant sein. Oder werden die "nativen Zeichenfunktionen" vom VDR vom Ausgabeplugin überschrieben, um auch diese notwendigen Berechnungen per GPU zu machen?


    Ciao Louis

  • Hi Copperhead,

    So richtig verstehe ich das im Moment noch nicht. Ob das nicht zu unvorhergesehenen Nebeneffekten führt... Ich schaue es mir gleich mal an.


    es ist eigentlich ganz einfach: du musst anstelle des transparenten invertierten Ellipsenteils (für die linke obere Ecke z.B. quadrant="-2") einfach den entsprechenden mit der Hintergrundfarbe gefüllten Ellipsenteil (quadrant="2") benutzen. Du musst also nur alle Minuszeichen von den Quadranten entfernen und die Farbe anpassen ;)


    Wenn man das in der SkinDesigner Syntax hat, kann man da etwas besser auf geänderte Seitenverhältnisse reagieren.


    Jo, das war die Idee ;)


    Ciao Louis

  • Cairo unterstützt GPU-Hardwarebeschleunigung, ich erinnere mich dazu vor Jahren mal häufiger News gelesen zu haben. Ich weiss aber wirklich nicht, wie das in diesem Kontext aussieht.

    - HTPC mit zerbasteltem Yavdr 0.6 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Digibit R1, Kodi und vdr an Pana 46PZ85E
    - Diverse HTPCs im Umfeld bei Familie und Freundenm die sich vor mir fürchten, mit allen möglichen gruseligen Konfigurationen.
    Auch gern Debian, aber wehe jemand kommt mir mit Suse.

  • Was mir eben noch einfällt...ich cache die einzelnen mit Cairo erstellten VDR cImages übrigens beim Start vom Skindesigner...die liegen also "fertig" im Speicher. Ich denke, da kann man durch GPU Unterstützung zur Laufzeit auch nicht mehr so wirklich viel rausholen ;)


    Ciao Louis

  • Oder werden die "nativen Zeichenfunktionen" vom VDR vom Ausgabeplugin überschrieben, um auch diese notwendigen Berechnungen per GPU zu machen?

    Genau das wird gemacht. Nennt sich offiziell "High-Level-OSD" und wird auch von der TT S2-6400 unterstützt.


    Gerade auf dem Raspberry Pi erhöht das die Reaktionsgeschwindigkeit ungemein. Ich fände es schade, wenn skindesigner hier "dagegen arbeitet", ich wollte mir dein Plugin nämlich auch mal anschauen und mir bei Gelegenheit einen hübschen Skin basteln. ;)


    Gruss
    Thomas

  • Hi Thomas,


    Genau das wird gemacht. Nennt sich offiziell "High-Level-OSD" und wird auch von der TT S2-6400 unterstützt.


    Ah ok...prinzipiell könnte ich das ganze natürlich auch optional machen, ob die nativen VDR Methoden oder Cairo benutzt wird. Wobei dann wahrscheinlich das antialiasing wegfällt...und die ganzen schönen extra Funktionalitäten auch. Ich denke aber wirklich, dass durch das Caching kein spürbarer Unterschied erkennbar sein dürfte.


    Gerade auf dem Raspberry Pi erhöht das die Reaktionsgeschwindigkeit ungemein. Ich fände es schade, wenn skindesigner hier "dagegen arbeitet", ich wollte mir dein Plugin nämlich auch mal anschauen und mir bei Gelegenheit einen hübschen Skin basteln.


    Na das wäre doch schade wenn das nicht klappen würde ;)


    Ciao Louis

  • es ist eigentlich ganz einfach: du musst anstelle des transparenten invertierten Ellipsenteils (für die linke obere Ecke z.B. quadrant="-2") einfach den entsprechenden mit der Hintergrundfarbe gefüllten Ellipsenteil (quadrant="2") benutzen. Du musst also nur alle Minuszeichen von den Quadranten entfernen und die Farbe anpassen

    So richtig gefällt mir das nicht... Es wäre logischer, wenn ich den Bereich mit einem drawrectangle selber leeren müsste...



    Edit: SkinElchi ist davon auch massiv betroffen. Irgendwie macht mir das zu viel kaputt... Die negativen Quadranten sind ja auch nicht grundlos da.

  • So richtig gefällt mir das nicht... Es wäre logischer, wenn ich den Bereich mit einem drawrectangle selber leeren müsste...


    Das passt aber nicht zum Konzept von "antialiasing". Prinzipiell würde das schon funktionieren, aber dann müsste man jeden einzelnen Pixel des Images mit dem darunterliegenden schon gezeichneten Pixel der Pixmap überblenden. Das würde dann aber den Rechenaufwand zur Laufzeit enorm erhöhen. Deshalb ist es wesentlich einfacher, den "positiven Anteil" zu zeichnen.


    Ciao Louis

  • Die negativen Quadranten sind ja auch nicht grundlos da.


    Die haben ja auch immer noch ihre Berechtigung...aber nur, wenn sie auch mit einer nicht komplett Transparenten Farbe gezeichnet werden. Denk mal drüber nach, das hat schon alles seinen Sinn ;)

  • Wobei dann wahrscheinlich das antialiasing wegfällt...

    Antialiasing ist Sache des Ausgabeplugins.


    Ich denke aber wirklich, dass durch das Caching kein spürbarer Unterschied erkennbar sein dürfte.

    Doch. Selbst wenn das im rpihddevice dann implementiert ist (momentan ist die default-Implementation des VDRs aktiv), müssen die Grundformen erst gezeichnet werden. Und das passiert mit einem High-Level-OSD immer effizienter, im Fall von rpihddevice mit OpenVG. Hier kriegt die GPU lediglich einen Vektor und kann diesen dann beliebig gross und bunt mit perfektem Antialiasing und ohne zusätzliche CPU-Last zeichnen.


    Ausserdem finde ich das Cachen von Grundformen die das OSD-API abdeckt grundsätzlich ein wenig fragwürdig… IMHO ist diese Funktion für eher für Sachen wie Kanallogos oder Menü-Icons gedacht.


    PS: wie stehen denn die Chancen, dass es so ein High Level OSD auch für softhddevice gibt?

    Da aktuelle Desktop-CPUs mehr als genügend Leistung mitbringen, wird der Druck sowas zu implementieren wohl nicht allzu gross sein.


    Bitte versteh mich nicht falsch. Ich finde skindesigner als Nachfolger von text2skin eine tolle Sache! Aber das eigentliche Zeichnen des OSDs sollte wirklich Sache des Ausgabeplugins bleiben.


    Gruss
    Thomas

  • Mit Ubuntu 12.04 LTS baut das Plugin nicht mehr:

    Gruß
    Frodo

  • Ich stimme reufer da zu.


    Ich habe auch lange darüber nachgedacht, ob es sinnvoll ist, sowas wie "Drawellipse" mit Cairo zu machen. Aus verschiedenen Gründen habe ich das aber verworfen.


    Zum einen hat mich gestört, dass die Syntax und auch die Funktion als solche sich verändert. Hätte ich eine Lösung gefunden, um ohne Funktionsänderung sowas umzusetzen, hätte ich mich darauf eingelassen und das ganze über die Plugin-Einstellungen konfigurierbar gemacht. Das vorhandene "DrawEllipse" zeichnet "über die Pixmap". Man kann also transparent eine Außenfläche z.B. auf einen Farbverlauf malen und der Teil wird abgeschnitten. Kann man so nicht ohne weiteres nachbauen weil der VDR einem die "Pixel" nicht wieder rausrückt. Das "neue DrawEllipse" im Skindesigner kann also nur Radien an Vollfarbige Flächen malen. Man kann kein DrawImage oder ähnliches im Nachgang "runden".


    Weiterhin bin ich der Meinung, dass man, wenn man es unbedingt will, auch ohne einen Verzicht auf das "DrawEllipse" aus dem VDR, Radien mit Cairo malen kann. Einfach einen Halb- oder Viertelkreis in SVG erzeugen und als Skinpart mitliefern. Wenn das noch nicht geht weil der Skindesigner hier die Platzierung unmöglich/kompliziert macht, dann sollte besser das gefixt werden (habe es noch nicht ausprobiert).


    Nicht zuletzt entfällt die Möglichkeit einer Hardware-Unterstützung beim OSD-Zeichnen. Eben aus dem Grund rückt der VDR auch Pixel nicht mehr raus. Um sicherzugehen, dass die Hardware hier der "Herr über die Pixel" bleibt.


    Der meiner Meinung nach beste Weg wäre Implementierung von Anti-Aliasing direkt im VDR. Ich habe Klaus wegen dem Thema vor einigen Wochen schonmal angeschrieben und er hat hier Unterstützung zugesagt. Ich erinnere in dem Zusammenhang nochmal an: http://www.linuxtv.org/pipermail/vdr/2012-June/026419.html Steht ja auch im VDR-Sourcecode, dass das noch fehlt. Eventuell sieht ja hier jemand eine Herausforderung darin das mal zu probieren? Ich habe mir das mal ganz unten auf meine ohnehin viel zu lange TODO-Liste geschrieben. Eben weil ich darin die sinnvollste Lösung sehe. Ich kann aber nicht versprechen, dass ich bis Ende 2015 auch nur annäherend dazu komme.


    An der Stelle komplett von der VDR-Funktion abzukoppeln halte ich auf jedem Fall für ein falsches Signal. Kleines SVG mit einer Halb- oder Viertelrundung mitzuliefern bringt das gleiche und es ist dann direkt offensichtlich, dass es sich um einen Workaround handelt der entfällt sobald der VDR selbst Anti-Aliasing kann. Vor allem kann man dann wieder zurück, denn die VDR-Funktion wird sich von der Syntax sicher nicht ändern selbst wenn Anti-Aliasing dazukommt.

  • Moin,


    na da habe ich ja was angefangen :D Ich kann die Argumente von Thomas und M-Reimer durchaus nachvollziehen. Wir haben da halt jetzt einen klassischen Deadlock...sicherlich wäre es am schönsten, wenn der VDR selbst antialiased Ellipsen zeichnen könnte. Kann er aber nicht. Und wenn das rpihddevice ein HighLevel OSD implementiert, das antialiasing kann und alles schön zeichnet, softhddevice das aber nicht kann, bringt das den meisten Usern auch nix.


    Ich habe kein Problem, das ganze wieder rauszuschmeissen...irgendwie fände ich es aber schade, auf die ganzen schicken weiteren Funktionen, die ich oben aufgelistet habe, zu verzichten. Die würden nach der Argumentation ja auch keinen Sinn machen oder?


    DrawEllipse könnte man dahingehend im Skindesigner erweitern, dass man neben der Farbe der Ellipse oder des Teils der Ellipse auch noch eine Hintergrundfarbe definieren könnte. Damit könnte man den bisherigen Effekt, dass man mit einem transparenten invertierten Ellipsenteil eine Ellipse abrunden kann nachstellen. Das funktioniert jedoch auch nur, falls der Hintergrung monochrom ist. Bei Farbverläufen oder Bildern als Hintergrund hätte man da wieder ein Problem.


    Ciao Louis

  • Mit Ubuntu 12.04 LTS baut das Plugin nicht mehr:


    Das liegt an der Konstanten "CAIRO_ANTIALIAS_BEST", die wurde erst mit Cairo 1.12 eingeführt. Ersetze die doch bitte mal durch "CAIRO_ANTIALIAS_SUBPIXEL", das ist der identische Parameter, den gibt es schon seit der 1.0.


    Ciao Louis

  • Statt "drawobject" solltest du es "drawpolygon" nennen. Das ist dann nicht so abstrakt.


    Hehe...das ist mir nicht eingefallen, als ich mir das ausgedacht habe ;)


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!