[FMX] eigene Komponente (Aufbau & Performance)

[stahli]

Sollen diese Controls eine Interaktion ermöglichen oder nur Werte darstellen?
Im Sinne Gauge, Oszillator oder Panel mit Zahlenwerten?

Wenn keine Interaktion erforderlich und Performance wichtig ist würde ich - gerade unter FMX - alles selbst regeln.
Also auch die Scrollbar und den sichtbaren Ausschnitt selbst berechnen und nur in diesem "virtuellen" Bereich eine Grafik berechnen und zeichnen.
Je nach Ausgangslage immer den gesamten sichtbaren Bereich oder auch nur den jeweiligen grafischen Bereich des Controls, in dem Daten geändert wurden.

Wenn eine Interaktion erforderlich ist wäre die Verwendung von FMX-Controls evtl. einfacher. Aber mit einer hohen Performance wird das vermutlich schwer zu vereinbaren sein.
Es kann sogar sein, dass das heute vielleicht ganz gut klappt und mit den nächsten Updates wird wieder etwas geändert, so dass Dein Konzept dann nicht mehr performant läuft.

Also ich würde in einem solchen Fall so viel wie möglich selbst regeln und zeichnen.

[sintronic86]

Zunächst mal danke für eure schnellen und interessanten Antworten!

Zitat von Der schöne Günther:

Warum es für so etwas grundlegendes nichts gibt ist mir auch rätselhaft. Schau mal hier, etwas besseres ist mir bislang auch nicht eingefallen:
http://www.delphipraxis.net/190153-p...ml#post1346910

Ist mir auch schleierhaft. Ich nutze solche Funktionalitäten häufig. Ich werde mir dein Beispiel bei Zeiten mal ansehen!

Zitat von Zacherl:

...Wie wäre es denn, wenn deine Komponente die Möglichkeit hätte, mehrere Datensätze untereinander anzeigen zu lassen und selbstständig zu scrollen?...

Leider geht das so nicht. Es ist definitiv gewollt, das eine Komponente nur einen Datensatz anzeigen soll. Vor Allem, da keine "Zeilen-Ansicht" vorgesehen ist und sie nicht nur untereinander, sondern auch nebeneinander stehen sollen (TFlowLayout).

Zitat von stahli:

Sollen diese Controls eine Interaktion ermöglichen oder nur Werte darstellen?

Die bisherige Planung sieht auch Interaktionen vor. So sollen z.B. 1-2 TCheckBoxes drauf.

Zitat von stahli:

... Also auch die Scrollbar und den sichtbaren Ausschnitt selbst berechnen und nur in diesem "virtuellen" Bereich eine Grafik berechnen und zeichnen.

Das Scrollen sollte schon automatisiert vom Parent (TScrollBox) übernommen werden. Ob eine Komponente gezeichnet werden muss oder nicht, weiß sie ja im Prinzip selber.

Zitat von stahli:

Je nach Ausgangslage immer den gesamten sichtbaren Bereich oder auch nur den jeweiligen grafischen Bereich des Controls, in dem Daten geändert wurden.

Und genau da sehe ich aktuell nicht durch.
Überschreibe ich die "Paint"-Procedure, könnte ich auf dem eigenen Canvas zeichnen. Wie kann ich an dieser Stelle aber ermitteln, welcher Bereich überhaupt neugezeichnet werden muss? Um zu wissen, das der Bereich eines bestimmten Wertes erneuert werden muss, brauche ich ja lediglich auf Änderung der Werte zu reagieren. Aber wie bekomme ich die anderen Bereich raus? Bspw. wenn ein anderes Fenster meine Komponente ganz oder teilweise überdeckt hat?

Habe ich denn eine Möglichkeit, das Paint nicht direkt anzufassen, sondern gesondert auf die Zeichenfläche zu zeichnen und der Komponente selbst das Aktualisieren zu überlassen?

[stahli]

Wenn Du viele eigene Controls erstellst (ähnlich Panel), die sich selbst zeichnen, dann musst Du FMX vertrauen, dass es die Neuzeichenaktionen sinnvoll veranlasst.

Bei meinen frühen Versuchen mit XE3 habe ich da allerdings regelrechte Neuzeichnen-Orgien festgestellt. Jede Änderung wurde MINDESTENS 3 mal neu gezeichnet und es wurden bei jeder Aktionen auch jede Menge abhängige Controls auch wieder neu gezeichnet.
Also da es Dir auf Performance ankommt würde ich an Deiner Stelle

-> ein großes Control erstellen, das eine Zeichenfläche und eine (auch selbst gezeichnete) Scrollbar enthält.

Dann platzierst Du virtuell mehrere Sichten für auf Deine Daten-Objekte und lässt diese sich in ihren Bereich zeichnen.
Klickt der User in den Bereich der Komponente, wo die Scrollbar gemalt ist, berechnest Du einen neuen sichtbaren Bereich, malst den Slider an die neue Position und lässt jetzt die Controls 100-120 aus den insgesamt 500 Datenobjekten in die Zeichenfläche malen.

Das macht mehr Aufwand, aber so kannst Du es m.E. am besten optimieren.

[mensch72]

solltest du das "TMS FMX (UI) ComponentPack" haben, wäre dort wohl die "TTMSFMXTileList" das was du suchst...

Ist zwar eigentlich für "Kacheldesign", macht aber um die Ecke gedacht genau das was du willst:
- kann beliebig viele verschieden große Objekte automatisch angeordnet anzeigen
- hat Events "pro Element" zum Selbstzeichen oder zuweisen der Daten
- TMS zeichnet/aktualisiert nur das was gerade angezeigt wird

Für einen schnellen Versuch, würde ich mir selbst pro Objekt intern ein Bild rendern(Größe&Inhalt ergo 100% frei und selbst bestimmt).
Wenn sich was ändert, dann zunächst wieder selbst für das Objekt das Bild intern neu rendern, dann schaun ob es "sichtbar" ist und ein Invalidate auf dessen Position absetzen, alle "Kacheln" stellen per Eventfunktion nur ihr zugehöriges Objektbild dar... fertig.
(Neuzeichnen bei/nach Fremdüberdeckung klappen so auch automatisch, weil das die GUI das Invalidate der betreffenden Regionen selbst auslöst)

Wenn kein TTMSFMXTileList oder das (noch)nicht passt, dann würde ich von dort nur den internen AutoLayoutTeil nutzen mir darauf meine Komponente mit einem "EventsPerObject" Konzept und eigener/virtueller Datenhaltung möglichst über "Pufferbilder" realisieren. Solange der Speicher für die Bilder reicht, ist das (Zeit)Verhalten der GUI somit unabhängig von der Anzahl der Objekte und der Ursache der Aktualisierung immer deterministisch und 100% "non Blocked" wenn man das rendern der Pufferbilder sauber asyncron mit Threads ausserhalb des GUI/Main Treads realisiert.

[sintronic86]

Hallo Leute,

bitte entschuldigt die verspätete Antwort.

Ich habe jetzt für alle meine genannten Probleme eine Lösung gefunden und möchte euch und natürlich auch allen, die evtl. nach mir an diesem Thema interessiert sind, meine Ergebnisse nicht vorenthalten.

1. Zu der Autosize-Property des TFlowLayouts:
Ich habe einen Nachfahren von TFlowLayout erstellt und diesem die gewünschte Property einfach selbst mitgegeben. Natürlich muss ich dann alle proceduren überschreiben, in denen eine Neuberechnung der Größe erforderlich ist:
- DoAddObject() - sobald dem FlowLayout ein Object hinzugefügt wird
- DoRemoveObject() - sobald vom FlowLayout ein Object entfernt wird
- Resize() - sobald sich die Größe des FlowLayouts ändert (bspw. durch vergrößern der Form, etc.)

Code:

  TFlowLayout = class(FMX.Layouts.TFlowLayout)
    private
      FAutoSize           : Boolean;
      FIsInAddRemoveObject: Boolean;

      procedure SetAutoSize(AAutoSize: Boolean);
    protected
      procedure DoAddObject(const AObject: TFmxObject); override;
      procedure DoAutoSize; virtual;
      procedure DoRemoveObject(const AObject: TFmxObject); override;
      procedure Resize; override;
    public
      constructor Create(AOwner: TComponent); override;

      property AutoSize: Boolean read FAutoSize write SetAutoSize;
  end;

Bisher funktioniert das wirklich einwandfrei!


2. Zu der Problematik meiner Komponente:
Ich habe jetzt eine wirklich performante Lösung gefunden, mit der ich mehr als zufrieden bin.
Meine Komponente ist ein Nachfahre von TControl. Und das ist auch das einzige Object, welches pro Komponente verwaltet werden muss, da ich die Oberfläche vollständig selbst zeichne.
Ich hatte anfänglich ja einige Schwierigkeiten mit der Paint-Procedure und den Entscheidungen, was genau neugezeichnet werden muss. Als ich mir dann aber das TImage genauer angesehen habe, habe ich festgestellt, dass dieses bei jedem Aufruf der Paint-Methode IMMER seinen GESAMTEN Bereich erneuert.
Es läuft jetzt folgendermaßen ab:
- Die Komponente hält ein "temporäres" TBitmap vor, auf das alle Sachen gezeichnet werden. Da dieses ja nicht sichtbar ist, gehen die Zeichen-Routinen sehr schnell von der Hand.
- Es gibt auslösende Events (mal von außen, mal von innen), die der Komponente mitteilen, das zumindest ein gewisser Bereich neugezeichnet werden muss
- Diese "Änderung" speichere ich innerhalb der Komponente und sage dann

Code:

Self.InvalidateRect(<< ein RectF >>);

Dadurch weiß die Komponente, dass sie neugezeichnet werden muss, wenn es soweit ist.
- Das daraus resultierende Aufrufen der "Paint"-Methode erfolgt erst dann, wenn die Komponente tatsächlich im sichtbaren Bereich ist. Das wird vom Framework gesteuert, muss ich mich also nicht drum kümmern.
- In der Paint-Methode gehe ich dann meine Änderungen durch, zeichne die entsprechenden Bereiche auf mein temporäres TBitmap und kopiere dieses am Ende IMMER auf das Canvas meiner Komponente.

So habe ich jetzt mal einen kleinen Test gemacht:
1000 * meine Komponente (wobei aus Platzgründen nur ca. 70 zeitgleich zu sehen sind) => neuzeichnen eines Bereichs alle 200ms => und es läuft, und es läuft, und es läuft....



Ich hoffe, ich konnte verständlich erklären, wie ich das jetzt gelöst habe. Wenn nicht, fragt einfach!
Und nochmal vielen Dank an alle, die sich die Mühe gemacht haben, mir Ideen zu liefern.