[FMX] Komische Linien und unvollständiges Repaint

[Rollo62]

Du kannst dir einen eigenen "CustomStyle" erzeugen (rechte Maus Edit custom Style), und in dem enthaltenen TRectangle Element das entsprechende Stroke.Kind auf None setzen.

[Medium]

Das hatte ich schon getan, und es ändert nichts an dem Problem leider.

Ich habe aber mal testhalbar das Repaint jeder einzelnen Komponente beim Zuweisen z.B. einer neuen Farbe herausgenommen, und stattdessen nach einem Updatezyklus das gesamte Panel neuzeichnen lassen. Siehe da: Linen und unvollständiges Zeichnen sind weg! Da scheint FMX tatsächlich ein wenig ... sagen wir seltsam zu arbeiten.

Die Linien tauchen vermutlich auch nur sichtbar bei mir zutage, weil ich das mittlere Frame mittels seiner Scale-Property auf die Größe seines Parent-Panels skaliere, wodurch vormals Integer-Koordinaten nun Nachkommaanteile erhalten. Aus eigener Erfahrung weiß ich, dass das im Zusammenspiel mit 3D-APIs immer so eine Sache ist. Das Batching (von dem ich mir mittlerweile fast sicher bin, dass es stattfindet), scheint zudem etwas ungünstig hereinzuspielen.

Verwandte Probleme habe ich zudem auch bei den Edits bemerkt: Wenn man diese skaliert, kann man teilweise ganz leicht deren interne Unterteilung in die verschiedenen Hintergrund-Bitmap-Bereiche erkennen. Sieht so sch... aus wie es klingt. Aber ich werde ohnehin noch eigene Edits machen, da mir die Nutzung von Bitmaps (bei einer Vektor-API verdammt noch eins, wer tut sowas??) die Einfärbung der Edits in beliebige Farben unmöglich macht. (Außer ich erstelle 16 Mio. Bitmaps mit den jeweiligen Farben gefüllt, und eben so viele Styles die ich dann zuweisen kann ) Was ich aber brauche.


Mannometer. Mit FMX hat man zwar tolle Möglichkeiten, aber man muss aber mal ECHT wissen wie der Eumel so im Detail tickt um nicht auf solche Sachen hereinzufallen. Alles noch etwas unreif scheint mir.

[Darlo]

Hi,

ich habe die nervigen Linien auch. Hängt leider mit dem skalieren zusammen. Außer mehrmals repainten hat noch nichts geholfen...

[Medium]

Ich frage mich, warum man diesen komplexen Weg für simple GUI-Anwendungen geht. Bei größeren Spielen, wo es Millionen von Draw-Calls wären wenn jedes Dreieck einzeln gezeichnet würde macht Batching ja Sinn, und man hat auch weit weniger das Problem mit Polygongrenzen die durch Floats (und evtl. zusätzlich AA) nicht mehr 100%ig präzise sind (da es weit weniger auffällt). Bei ein paar popeligen (maximal!) hunderten von kleinen GUI Quads scheint mir das doch arg mit der Kanone auf den Spatz geschossen. Selbst mit Blick auf Mobile. Da würde mich tatsächlich der Grund für die Entscheidung mal interessieren.

[Rollo62]

Also vom Skalieren lasse ich möglichst die Finger, das kommt dann auch den
MultiResBitmaps in die Quere, und den Scene und Bitmap Skalierngsfaktoren.

Was bei mir gut klappt ist ein Panel mit Align setzen,
und darin dann ein Image oder Glyph zeigen, auch mit Align = Client z.B.,
und das Bitmap selbst dann evtl. vorskalieren, falls nötig.

Rollo

[Medium]

Das wird so einfach leider nichts bei mir. Ich erstelle Industrieanlagenvisualisierungen, die dynamisch und interaktiv sein müssen. Nach Jahren des für spezifische Auflösungen arbeiten müssen habe ich mir nach dem Skalieren von FMX richtig saftig die Finger geleckt. Die Möglichkeit allein war bestimmt >30% an der Entscheidung beteiligt erneut auf Delphi zu setzen, nachdem wir mit unserem vorigen D2007 doch langsam etwas hinten an hingen.
Und mal unter uns: Skalierbarkeit ist doch auch mindestens das zweitwichtigste Argument für vektorbasierte GUIs so ganz generell gesehen schon. Das ist deren großes Feature. Also nutze ich das auch!

[Rollo62]

Dann probier mal TPath aus, damit kann man komplexe graphische Figuren Zeichen,
das funktioniert auch sehr gut bei mir.

http://docwiki.embarcadero.com/Libra...cts.TPath.Data

Rollo