'setCornerRadius' auch für 'ePixmap'

  • Hallo


    Reichi

    Wäre es kompliziert auch für ePixmap ein setCornerRadius zu integrieren ?


    Ich verzweifle gerade an der Farbgebung für window-Borderset-Grafiken als svg mit Transparenz (Alpha) und abgerundeten Ecken.

    Da stimmen dann leider die Borderset-Farben nicht mit dem gleichen Farbwert des Backgrounds der Screens überein.


    Wenn ich das Borderset mit color-Angaben anstelle des Grafikfiles verwende, passen die Farben zu 100%.

    Leider kann ich da aber keinen radius verwenden.


    Von daher wäre es echt super, wenn setCornerRadius auch für ePixmap ginge :winking_face:

    Ich denke mal, dass diese Variante auch einige Skinner freuen würde :thumbs_up:


    Ich sag einfach schon mal Danke :thumbs_up::grinning_face_with_smiling_eyes:


    Edit:

    Wobei man hier ja noch spezielle Atrribute bräuchte, um den Radius bei den Eckelementen auf nur eine bestimmte Ecke zu setzen.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    Einmal editiert, zuletzt von Sven H ()

  • Ok, dann mach ich da mal was fertig :winking_face:


    Du bräuchtest dann ja nur eine angepasste skin.xml und die passenden Borderset-Grafiken.


    Ich bin mir gerade nicht sicher, ob das nur beim Borderset auftritt oder auch innerhalb eines Screens nachstellbar ist. Muss ich nochmal testen.
    Bei letzterem könnte ich ja wieder ein einfaches Demo-Plugin erstellen.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Edit:

    Wobei man hier ja noch spezielle Atrribute bräuchte, um den Radius bei den Eckelementen auf nur eine bestimmte Ecke zu setzen.

    It's a very good idea, I've been asking about it for a long time, so that the radius can be applied to 1 corner. If you make curves for 'Pixmap', that would be cool. :thumbs_up:

  • Du willst zu ePixmap adäquat wie zu eLabel eine Parametrisierung mittels cornerRadius ...


    Dr. Best hat aber ePixmaps nur für Rectangles implementiert, das geht nicht so eben mal fix. Sonst hätte ich mir schon vor 2 Jahren eine MENGE Arbeit in den Skins sparen können, indem ich Farbverläufe mit gleichzeitig abgerundeten Ecken über


    <ePixmap gradient="mpgradbg,mpgradfg,vertical" ... cornerRadius="20" /> gemalt hätte. Geht aber nicht. Wird wohl auch nix :grinning_squinting_face:

  • Reichi

    Hab mal versucht, das Ganze verständlich zu gestalten :winking_face:


    1. Test-Plugin (für HD-Skin), wo man die Farbunterschiede ganz gut sieht (im Screenshot ganz links am Rand sieht man auch den Unterschied zum Border-svg)

    2. angepasste skin.xml für den Default Skin mit Color-Angaben im Borderset, wo die transparente Farbe zum Background passt

    3. angepasste skin.xml für den Default Skin mit svg-Borderset, wo die transparente Farbe nicht zum Background passt


    Background ist #0F353535 (RGB 53,53,53), Transparenz 0F (15)

    Wenn ich für das svg anstatt (53,53,53) einfach (57,57,57) bei Alpha 240 nehme, passt es optisch fast.

    Aber das ist ja nicht sinnvoll, wenn man da probieren muss, bis die Farbe passt - das sollte bei gleichen Farbwerten auch so passen.


    Und da das Borderset mit transparenten color-Angaben zu 100% passt, kam mir eben der Gedanke mit dem Radius fürs Borderset :winking_face:

  • Reichi

    Danke für den Tipp zum premultiplied alpha :winking_face:


    Hab mich da jetzt mal eingelesen.

    Demnach wird bei premultiplied alpha der Transparenzwert nicht nur im Alphakanal sondern zusätzlich auch in jedem Farbwert gespeichert.

    Bei der Anzeige des Bildes wird das dann natürlich auch wieder zurückgerechnet, weshalb die Farbe bisher nicht gepasst hat.


    Also muss man die Farbwerte für rot,grün,blau vom transparenten Label vorher auf das transparente premultiplied svg umrechnen.


    Hab mir da jetzt folgende Formel gebildet:

    Code
    transpfactor = (256 - Transp-Value) / 255.0
    red = round(red / transpfactor,0)
    green = round(green / transpfactor,0)
    blue = round(blue / transpfactor,0)

    Somit wird bei Transparenz 15 (Alpha 240) aus dem Label-Farbwert (53,53,53) dann der passende svg-Farbwert (56,56,56).


    Bei einigen Tests mit verschiedenen Transparenzen und verschiedenen Farben, war nun kein Unterschied mehr feststellbar :winking_face:

    Hab dazu sogar extra Screenshots erstellt und die Farben (Background + Border) mit einer Farb-Pipette ausgelesen und verglichen.


    Im Screenshot aus dem Test-Plugin sieht es jetzt auch gut aus :winking_face:

    Musste allerdings nur beim ePixmap-gradient anstatt (56,56,56) hier (59,59,59) verwenden - keine Ahnung, warum man da noch mehr hochrechnen muss.

    Aber vom Prinzip ist ja jetzt erstmal die Sache mit der svg-Farb-Transparenz geklärt :winking_face:


    Oder wolltet/müsst ihr da evtl. intern noch was glattziehen ?

    (weil das ja beim gradient nicht ganz passt)

  • Danke für die Rückinfo. :thumbs_up:

    Hoffentlich kann es gefixt werden. Würde es jedenfalls deutlich einfacher machen, wenn man überall die gleichen Werte mit gleichem Ergebnis verwenden kann.

    Bis dahin kann ich ja meine Wunder-Formel verwenden :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Super :thumbs_up:

    Betrifft das dann beides (also ePixmap gradient und svg's mit Transparenz) ?

    Dann sind also ohne weitere Farb-Korrektur die Farben im obigen Test-Plugin jetzt passend ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Zum Test hab ich wie gesagt immer einen Screenshot von einem Plugin-Screen gemacht und in einem Grafiktool dann die Farbewerte für den Borderbereich und den Backgroundbereich mit der Farbpipette abgefragt.

    So wusste ich, wann die Formel zu 100% passt :winking_face:

    Nur mit den Augen war ich mir da bei den vielen Tests nicht mehr so sicher - irgendwann sieht man was, was gar nicht da ist :grinning_squinting_face:


    Dabei hatte ich dann auch gemerkt, dass ich bei der Formel (256 - Transp) / 255.0 rechnen musste.

    Bei (255 - Transp) / 255.0 war der Transparenzwert des Borders im Screenshot immer um 1 zu niedrig im Vergleich zum Background-Transparentwert.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Ok. :thumbs_up:

    Muss man dann im Borderset auch alphatest="off" setzen?

    Oder gilt das nur ePixmaps-widgets?


    Im Borderset gibt es das ja glaub ich nicht.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    • Offizieller Beitrag

    Es gilt nur weil das Fenster einen schwarzen Hintergrund hat, auch wenn er voll transparent ist scheint das Auswirkungen zu haben.

    Pixmaps werden default geblendet, der text steht auf transparent="1" was alphatest="off" entspricht


    Gibst du dem screen als Hintergrund z.B. #FFFFFFFF wirst du feststellen, dass die geblendeten Inhalte "zu hell" werden.

    Da Alpha-Blending auf flächig-voll transparente Hintergründe aber eher Ausnahme als Regel ist wird das i.d.R. aber so gut wie nie auffallen :winking_face: (merkt man auch daran, dass du der Erste bist der das meldet).


    Aktuell "ist das halt so".

    Da es auf allen Boxen identisch ist, sollte man damit umgehen/leben können.


    Nachtrag:

    Es ist einer notwendigen Vereinfachung des Alpha-Blending Algorithmus geschuldet, welche an einer Stelle den Alpha-Wert des "Ziels" nicht mit einbezieht.


    Die technisch korrekte Formel (für die Farbe) lautet:

    Code
    src_color * src_alpha + dst_color * dst_alpha * ( 1 - src_alpha)


    Eingesetzt wird:

    Code
    src_color * src_alpha + dst_color * (1 - src_alpha)
  • Hatte gestern nochmal mit dem obigen Test-Plugin gespielt und beim transparenten gradient-ePixmap die Colorwerte (56,56,56) anstatt der zusätzlich erhöhten Werte (59,59,59) mit alphatest="off" kombiniert.

    Dabei passte dann die Farbe zum gleichfarbigen svg (56,56,56) und dem transparenzen Label mit (53,53,53) :winking_face:


    Und mit dem Patch denke ich, dass man dann auch (53,53,53) beim transparenten svg und dem transparenten gradient ePixmap verwenden kann (also ohne Umrechnung auf 56,56,56) und es dann zum gleichfarbigen Label (53,53,53) passt, oder ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP