Hi,

Ich habe hier ein ganz schön ärgerliches Problem. Die Performance von Measuretext und Filltext ist unterirdisch bei D2D und unter OSX. Das konkrete Beispiel ist ein 80x25 Zeichen großes Textfeld in einem Canvas (einfach ausgedrückt). Die Zeichen werden einzeln Nacheinander in das Canvas geiendert. Erst die Breite des Zeichens bestimmt und dann mit Filltext an die Position gebracht. Das geschieht sekündlich und ist extrem langsam. Mit GDI+ habe ich eine Prozessorlast von weniger als 1%, bei D2D und unter OSX ist das eine Last von 10%. Ich kann das zwar durch einen Rasterizer umgehen (es werden die Zeichen in Texturen gespeichert und dann von da Auschnittsweise kopiert). Für das Problem ist dies aber leider nicht anwendbar. Und nein es geht auch nicht das anderweitig zu realisieren.
Im Prinzip brauche ich das nur unter OSX. Kennt Jemand eine alternative Methode dort ein Textzeichen auf ein Canvas zu rendern?

Peter

Zitat von Peter666:

Im Prinzip brauche ich das nur unter OSX.

Wäre es hier vermessen, auf ein Programmiertool zu verweisen, dass auf der Plattform etwas heimischer ist als Delphi?

Jein, das komplette Projekt besteht aus 6mb Quellcode und ich zur gänze möchte ich es ungern nach ObjectiveC umsetzen, davon abgesehen finde ich XCode und ObjectiveC nicht so hübsch wie Delphi.

Edit: Ignorieren

Schau dir doch mal diesen Artikel an:

StackOverflow

Da gibts noch ein paar Booleans die man auf True/False stellen könnte für die Performance

Oder besser gleich auf Vektorgrafik setzen, den das ist die Grundlage von FMX

Hallo Markus, irgendwie wusste ich das das jetzt kommt - Nein das Problem ist definitiv nicht mittels Vektorgrafik zu lösen, davon abgesehen bringt das auch nix. Ich frage mich warum man stets unbelesen dieses "Totschlagargument" widerkäut. Die Basisfunktionen (dazu gehört die Textausgabe) bauen auch auf das was unter FMX.Canvas.MAC, FMX.Canvas.GDIP bzw. D2D hinterlegt ist auf. Was nützt mir eine Ferrarikarosserie, wenn darunter ein Trabbimotor werkelt? Das zieht sich wie ein roter Faden durch das ganze Firemonkey. Überall wo man reinguckt findet man Codepassagen, wo man sich ernsthaft fragt wer so etwas durchgehen lässt. Was nützt mir ein optimierter Rest wenn die Grundfunktionen so dermaßen unperformant sind das jeder Versuch etwas zu optimieren fehlschlägt.

Auch extrem nervig sind die Memoryleaks, so fehlt beispielsweise bei: procedure TCanvasQuartz.FillText ein CFRelease(str); am Ende und das gleiche gilt bei MeasureText. Das sind nur die beiden Funktionen die ich mir problembezogen angeguckt habe.

Peter

Weil man hat saut blöd ist. Aber man überlässt die Sache nin den absoluten Spezialisten.

Naja ich halte mich nicht für einen Spezialisten und ehrlich gesagt bei dem Preis was ein Upgrade kostet sehe ich das auch gar nicht ein.
Ich habe meinen alten Font-Rasterizer ausgekramt und auf Firemonkey lauffähig gemacht - ursprünglich war dieser für OpenGL und D3D Zwecke entstanden.
Der erstellt bei Bedarf die gewünschten Unicodezeichen in einer bzw. mehreren (wenn Platz nicht ausreicht) großen Textur(en) und übergibt die notwendigen Koordinaten.
Das ist zwar nicht das was ich erhofft habe, aber Cocoa will ich mir nicht wirklich antun.

Peter

Nachdem die XE4 Demo nun veröffentlicht ist, habe ich mal interessehalber damit "gespielt. Was mir gefallen ist, ist dass die Action-listen (gibts seit XE3, ich weiß) gut funktionieren und die Firemonkeykomponenten einfacher zu bedienen sind. Teilweise habe ich zumindest den Eindruck ist alles auch etwas flotter. Leider aber nicht so das ich das ernsthaft für Crossplattformentwicklungen nutzen würde. Insbesondere wenn man viel mit TBitmaps und Canvas arbeiten muss.
Das beiliegende Demo veranschaulicht das ganze (hoffentlich) etwas. Die Delphi7 Version (da nutze ich GDI+) ist um Faktor 1000 schneller. Mir ist klar das der Code in der Form nicht wirklich sauber geschrieben ist und das man einiges dabei beschleunigen kann, aber darauf kommt es mir nicht an. Ich habe mir auch keine Mühe bei der Portierung von Java (http://www.java4k.com/index.php?acti...d=view&gid=302) gegeben, deswegen auch die katastrophalen Variablenbezeichner und das alles in einer Schleife-Disaster.

Peter