[FMX] FillPolygon+DrawPolygon und Transparenzen

[Medium]

Huhu DP,

ich spiele aktuell mit meinem frisch erworbenem Delphi mit FMX herum. Ich versuche gerade unsere internen Komponenten zu portieren, und will sie dabei natürlich gleich auf die neuen Möglichkeiten aufbohren.

Derzeit versuche ich unser Symbol für Ventile (einfach zwei Dreiecke die sich an einer Spitze berühren) umzusetzen - abgeleitet von TShape. Dabei jetzt folgendes Problem:
Die Eigenschaft "Opacity" scheint so erstmal nichts zu machen. Man muss scheinbar selbst in seiner Paint-Methode dafür sorgen, dass der Wert beachtet wird und ihn an seine Canvas.Draw*-Aufrufe weitergeben. So weit kein Problem.
Es wird aber eines, wenn man ein Polygon (in diesem Fall sogar eines, dass sich selbst durchdringt) mit Rand und Füllung haben will - insbesondere dann, wenn der Rand dicker als 1px ist und man Transparenz sauber unterstützen möchte.

Normal ist ja: Erst den Fill zeichnen, und dann die Kontur "drüberjauchen". Das geht auch, solange keine Transparenz dabei ist. Mit dieser jedoch sieht man im Ergebnis, dass der Fill bis zur halben Dicke des Strokes reicht, da dieser ja nun auch transparent ist. Siehe Bild im Anhang. (Was dagegen sauber klappt ist der Kreuzungsbereich des Strokes. Sehr cool schon mal!)

Das Polygon ist definiert als:

Delphi-Quellcode:

p: TPolygon;
p[0] := PointF(0, 0);
p[1] := PointF(Width, 0);
p[2] := PointF(0, Height);
p[3] := PointF(Width, Height);

Ich hätte aber gerne, dass der Fill eben gerade nur bis zum inneren Rand des Strokes reicht! Skalieren des Polygons für den Fill fällt leider mit Selbstdurchdringung als Option flach. Gibt es dafür eine schöne Lösung?

[Rollo62]

Schonmal überlegt TPath zu nehmen, da kann man recht komplexe Figuren reinmalen.
Stroke und Fill funktionieren da genauso.

Rollo

[KodeZwerg]

Wenn ich richtig liege hat das was mit Anti-Aliasing zu tun. Versuche da eine andere bzw gar-keine Methode zu verwenden.

[milos]

Hi Medium,

hast du dir die Properties ClipChildren und ClipParent mal angesehen?

Diese bewirken dass Eltern-Komponente nicht über (bzw unter) Child-Komponente gezeichnet werden. Im Anhang findest du einen Vergleich.

Edit: Nach weiterem rumprobieren scheint es als würde dies nur für Rechteckige Komponente funktionieren. Tut mir leid war wohl zu voreilig...
Freundliche Grüsse

[bytecook]

Zitat von Rollo62:

Schonmal überlegt TPath zu nehmen, da kann man recht komplexe Figuren reinmalen.
Stroke und Fill funktionieren da genauso.

Rollo

Würde ich auch so machen, dann die Strokewidth (hws 0.5, 1 wird vermutlich eine Linie + zwei schwache Aliaslinien seitlich erzeugen) entsprechend setzen.
Ich arbeite zwar nicht (mehr) mit Firemonkey, sondern mit meiner ursprünglich von GR32 abgeleiteten Vektorgui, der Vorgang bleibt aber der gleiche.
Oftmals ist die Überlagerungstransparenz natürlich gewollt, manchmal, wie in deinem Beispiel natürlich hinderlich. Mit der Pfadvariante solltest du das hinbekommen.
In meinem Beispielbild findest du Resultate mit Breite 1 sowie 2. So sollte das auch in FMX möglich sein...

[Medium]

@Rollo62: Das sieht recht interessant aus. Da schaue ich mir mal an wie das mit dicken Konturen und Transparenz klar kommt.

@KodeZwerg: Stimmt, das AA kann einem dabei fies werden. Weiß ich noch von meinen Spielereien mit der Graphics32 in ähnlichen Situationen.
Hatte schon überlegt eine 100% deckende Version auf ein Bitmap zu malen, und das dann inkl. Opacity auf den Canvas zu bringen. Hier befürchte ich aber Performanceprobleme irgendwann, und mir wiederstrebt es in einer vektororientierten "Welt" vor Ankunft auf dem Bildschirm irgendwas zu rastern =)

@milos: Trotzdem ein sehr interessanter Hinweis! Bisher hatte ich keine Vorstellung davon was diese Properties machen. Danke!

@bytecook: Jup, wird definitiv getestet. Bischen schade ist, dass man - zumindest wie es in der Doku grad aussieht - die Punkte als String übergeben muss. Mal schauen wie sehr mich das stört =)
Darf ich fragen wieso du von FMX wieder zurück gewechselt bist? Ich mache nämlich auch gerade im Grunde genommen den Schwenk GR32->FMX. Dein Bild gefällt mir übrigens sehr! Selten, dass eine Maschinensteuerung so modern und aufgeräumt daher kommt, aber dennoch nicht langweilig ist.

[bytecook]

Zitat von Medium:

@bytecook: Jup, wird definitiv getestet. Bischen schade ist, dass man - zumindest wie es in der Doku grad aussieht - die Punkte als String übergeben muss. Mal schauen wie sehr mich das stört =)
Darf ich fragen wieso du von FMX wieder zurück gewechselt bist? Ich mache nämlich auch gerade im Grunde genommen den Schwenk GR32->FMX. Dein Bild gefällt mir übrigens sehr! Selten, dass eine Maschinensteuerung so modern und aufgeräumt daher kommt, aber dennoch nicht langweilig ist.

Danke für die Blumen Medium

Ich habe zwischen 2010 und 2012 versucht, meine graphischen Oberflächen mit VGScene und im Anschluß mit FMX zu machen. Da ich doch wegen Nichtverfügbarkeit diverser Komponenten ab 1997 sehr viele Komponenten selber entwickelt habe, setze ich immer recht tief in den verfügbaren Frameworks an. Leider wurde in FMX vieles von Version zu Version lowlevelseitig geändert, (die Performance wurde auch immer schlechter), sodaß ich irgendwann den Entschluß fasste, mein eigenes Framework aufzubauen. Habe dann zuallererst virtuelle Touchscreen Standardkomponenten entwickelt, alle Komponenten setzen sich rein aus Pfaden zusammen. Auch die "Schriftarten" und die "Icons" sind vektorisiert und sind in der Exe inkludiert, so ist gewährleistet, dass die Programme immer gleich auissehen. Ich habe durch verschiedene Optimierungen eine wesentlich bessere Performance als unter XE 7 hinbekommen, die Animationen sind flüssiger, und der Speicherverbrauch liegt bei ca 150 mb, obwohl ich 36 Vektorfonts und ca 2600 Vektorisierte Icons im Speicher halte. Zum Vergleich benötigten meine Programme unter FMX mehr als 1 Gb im Ram.

Warum schwenkst du eigentlich von GR32 weg nach FMX?

[Medium]

Zitat von bytecook:

Ich habe zwischen 2010 und 2012 versucht, meine graphischen Oberflächen mit VGScene und im Anschluß mit FMX zu machen. Da ich doch wegen Nichtverfügbarkeit diverser Komponenten ab 1997 sehr viele Komponenten selber entwickelt habe, setze ich immer recht tief in den verfügbaren Frameworks an. Leider wurde in FMX vieles von Version zu Version lowlevelseitig geändert, (die Performance wurde auch immer schlechter), sodaß ich irgendwann den Entschluß fasste, mein eigenes Framework aufzubauen. Habe dann zuallererst virtuelle Touchscreen Standardkomponenten entwickelt, alle Komponenten setzen sich rein aus Pfaden zusammen. Auch die "Schriftarten" und die "Icons" sind vektorisiert und sind in der Exe inkludiert, so ist gewährleistet, dass die Programme immer gleich auissehen. Ich habe durch verschiedene Optimierungen eine wesentlich bessere Performance als unter XE 7 hinbekommen, die Animationen sind flüssiger, und der Speicherverbrauch liegt bei ca 150 mb, obwohl ich 36 Vektorfonts und ca 2600 Vektorisierte Icons im Speicher halte. Zum Vergleich benötigten meine Programme unter FMX mehr als 1 Gb im Ram.

Warum schwenkst du eigentlich von GR32 weg nach FMX?

Uffza. 1GB ist üppig . Meine Komponenten sind bisher bei weitem nicht so komplex, und es sind auch bloß ~15 verschiedene. Alles Anlagensymbole. Buttons usw. habe ich bisher meist die von TMS genommen. Edits und Grids genauso. Meine bisherige Nutzung der G32 sah weitestgehend so aus, dass ich meine Symbole auf ein Offscreen-Bitmap32 zwecks AA gemalt habe, und das dann auf den Canvas geblitted. Davor war alles rein VCL basiert, und das habe ich im Prinzip damals 1:1 übernommen und AA mit G32 "drübergestülpt".
Bisher habe ich nur mit D2007 gearbeitet. 10.2.3 habe ich jetzt ganz neu, und somit das erste mal FMX in der Hand. Da unsere Komponenten definitiv eine Modernisierung brauchen, dachte ich, dass ich sie gleich mit FMX bastel, was sich konzeptionell für unsere Zwecke ja anbietet. Und ich fand's sehr nett dann gleich für potenzielle künftige Anfragen für mobile Lösungen gewappnet zu sein, ohne dadurch gleich vor einen kompletten Port unserer Lib gestellt zu sein. Und es ist halt eine Abhängigkeit von Drittkomponenten weniger. Auch wenn ich die G32 wirklich sehr sehr genial finde und schon viel damit gemacht habe, bin ich immer froh Abhängigkeiten minimieren zu können.
Es klang (bisher) schlicht sinnvoll, und aus meiner Perspektive ist es obendrein ein neues Spielzeug

[bytecook]

Mittlerweile ist FMX erwachsener geworden, und sicher auch performanter. Für unsere Zwecke wars aus verschiedensten Gründen letztendlich nicht so geeignet, da wir doch recht viel Daten graphisch für Drucksysteme aufbereiten, und die DPI Skalierungen der Druckausgaben anpassen müssen (Die schnelleren Drucker drucken mit bis zu 300 Meter/Minute).
Dafür setze ich ripseitig eher auf CPUs denn auf GPUs, gerade in Zeiten von AMDs Threadripper, und GR32 mit SSE2 und Co. kommen da gerade recht gut rüber.

Firemonkey wird ab Herbst auch für uns wieder interessanter, ein kleines Remote-Steuerprogramm-Projekt für unsere Gui unter Android ist für einen jungen Mitarbeiter vorgesehen.
Mal sehen, ob das klappt.

[Medium]

Danke für deine Ausführungen und viel Erfolg!