[FMX] Komische Linien und unvollständiges Repaint

[Medium]

Hallo DP!

Ich kann endlich an meinem ersten größeren FMX Projekt weiter machen, und habe auch gleich mal ein Problem. Im Angehängten Screenshot kann man dunkelgraue Linien bzw. Rahmen um größere Bereiche sehen. Diese gehören zu keiner Komponente die ich erstellt hätte, tauchen also quasi aus dem Nichts auf.

Zum Aufbau dessen was man dort sieht:
Basis ist ein FMX Form mit 3 Panels. Eines für je einen Kopf- und Fußbereich (im Bild nicht zu sehen), und den Zentralbereich. In den Zentralbereich setze ich via Quellcode ein Frame. In diesem Frame sind die eigentlichen Grafiken enthalten. Die Panels haben einen Style der ihnen die vormals als clBtnFace bekannte Farbe zuweist und sie rahmenlos macht.

Interessant sind hierbei zwei Beobachtungen:
1) Man erkennt in dem Bild z.B. bei den unteren Symbolen "Y04" und an dem Tank unten rechts, dass hier Dinge schief laufen. Zum Programmstart sehen alle Tanks in etwa wie die B01-B03 aus, werden aber kurz darauf anhand von Datenbankeinträgen größtenteils invisible gemacht. Das funktioniert manchmal komplett, und manchmal so halb wie ihr es hier sehen könnt.

2) Diese schemenhaften Rahmen verändern sich wenn ich das Fenster verschiebe oder in seiner Größe ändere. (Dann wird auch meist das zuvor genannte fehlerhafte Zeichnen korrigiert.) Die Linien werden mal blasser, mal stärker, und die Größe und Form der Rahmen ändert sich leicht.

Für mich sieht das irgendwie so aus, als würde FMX hier selbst versuchen das Fenster zu partitionieren um optimierte "gebatchte" Draw-Calls an DirectX machen zu können, scheitert aber sowohl an der Positionierung (daher ggf. die Rahmen, weil nicht 100%ig "float-korrekt") als auch an der korrekten Eingrenzung des neuzuzeichnenden Bereichs.

Liege ich da richtig? Wenn ja: Kann man das irgendwie beeinflussen? Wenn nein: Was könnte es noch sein?

Nochmals zur Sicherheit: Ich habe nirgends Komponenten, auch keine unsichtbaren, die in irgend einer Weise mit diesen Rahmen in Zusammenhang stehen könnten.

Vielen Dank für eure Ideen vorab!

Edit: Delphi 10.2.3 unter Win10 Pro 64

[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

[Medium]

Damit arbeite ich doch schon Alles in meinem Screenshot besteht aus selbst gebauten Komponenten, die sich hauptsächlich auf diese Weise zeichnen. Ich selbst habe keinerlei Probleme mit Bitmaps. Nur damit, wie FMX seine Draw-Calls organisiert und TEdits Implementierungsdetails.

[Rollo62]

Zitat:

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!

Ich habe meine ursprünglich genauso hohen Erwartungen an ein GPU beschleunigtes, vektorbasiertes UI leider ziemlich runtergeschraubt

In deinem Fall würde ich mal von Grund auf ein Demo aufbauen, und versuchen rauszufinden wann und wo genau es hakt.
Ich habe das leider auch schon gefühlte 1000x so machen müssen.

Es ist leider so dass das Fundament extrem stabil sein muss, und bei FMX steht man immer auf wackeligen Füssen, deshalb versuche ich herauszufinden was geht, und was nicht mehr.
Aber was rede ich, Das machst du wahrscheinlich auch schon lange so, und hilft dir jetzt gerade auch nicht weiter

Rollo