VCL vs. FMX - Die Frage ist (vorerst) offiziell beantwortet

**Uwe Raabe**

Wenn ich FMX unter Windows ausschließlich mit DirectX verwenden kann dann sind Programme
die als Beispiel in Windows Programmiert wurden unter Android, Linux oder was auch immer nicht lauffähig.

Das ist so nicht richtig!

Ein FMX-Programm lässt sich einfach durch Umschalten der Zielplattform auf allen von FMX unterstützen Plattformen (Win32, Win64, OSX, iOS, Android) compilieren. Insofern ist es völlig egal, welche Grafik-Schnittstelle unter der Haube verwendet wird, da dies innerhalb der Anwendung vollkommen gekapselt ist. Wenn Embarcadero in der nächsten Version für FMX unter Windows auch OpenGL nehmen würde anstatt DirectX, würde das den Sourcecode der Anwendung überhaupt nicht tangieren.

**Daniel**

FMX entscheidet selbst, auf welcher Plattform es auf welche Grafik-Schnittstelle aufsetzt, um seine Buttons, Panels und Edits zu malen.
Solange es auf jeder Plattform auf die jeweils "korrekte" Schnittstelle nutzt, ist alles in Butter. Und unter Windows wurde DirectX nunmal genau für diesen Zweck geschaffen. Darum nutzt man doch eine Bibliothek wie FMX (oder meinetwegen auch Qt), weil man sich um dieses Low-Level-Gelump gerade nicht kümmern will und auch nicht muss.

Wenn Du jetzt in Deinem Code explizit DirectX nutzt, dann ist das nichts anderes, als würdest Du explizite iOS- oder Andriod-Funktionalitäten nutzen. Dann ist es natürlich aus mit der Crossplattform-Fähigkeit. Dann ist aber nicht FMX das Problem, sondern Dein eigener Code. Da habt Ihr etwas verwechselt.

Dass das Firemonkey-Framework intern sehr viel plattform-spezifischen Code beinhaltet, liegt auf der Hand.

//edit: menno - jetzt war Uwe schneller.

Zitat:

Dann ist aber nicht FMX das Problem, sondern Dein eigener Code. Da habt Ihr etwas verwechselt.

Ok solange es sich um das Framework , Button usw.. handelt mag das dann hinkommen.
Was ist aber wenn ich nun mit FMX OpenGL Rendern möchte?
Dann tritt das ein was Fritz meinte.

Zitat:

Mixen von DirectX und OPENGL ist nur was für Masochisten.

Ob das nun das wahre ist mag dahingestellt sein.
Ok bin raus wollte das nur mal so im Raum stehen lassen.

gruss

**Mavarik**

Zitat von Daniel:

Wenn Du jetzt in Deinem Code explizit DirectX nutzt, dann ist das nichts anderes, als würdest Du explizite iOS- oder Andriod-Funktionalitäten nutzen. Dann ist es natürlich aus mit der Crossplattform-Fähigkeit. Dann ist aber nicht FMX das Problem, sondern Dein eigener Code. Da habt Ihr etwas verwechselt.

Es gibt halt Leute die wollen immer das Haar in der Suppe finden, auch wenn sie dafür ein Mikroskop brauchen...

Wenn ich mir die Änderungen der letzten 35 Jahren Softwareentwicklung anschaue, hatten wir es noch NIE so einfach unsere
Software auf unterschiedliche Betriebssystem zu portieren wie heute...

Entweder haben wir nur für eine CPU Code erzeugt, oder nur für eine bestimmte Grafikkarte. Wir haben API-Calls verwenden oder
Daten an fixe Portadressen rausgegeben... Memorystellen gepacht um Sounds zu erzeugen u.v.m.

Wenn man schnell seien wollte, musste man Hardware nah programmieren...

Diese Zeiten sind vorbei...

**jaenicke**

Zitat von EWeiss:

Dann hätte man bei Windows auch auf OpenGL bleiben müssen und kein Mixstatus generieren.
Dann ist es nicht mehr CROSSPLATTFORM kompatibel. Ein Widerspruch in sich selbst.

Wenn du so heran gehst, gibt es keine einzige Programmiersprache, die Cross Platform ist. Schließlich kannst du mit keiner unter x86 Prozessoren ARM-Code ausführen oder umgekehrt...

**Codehunter**

Das Thema Screenreader ist auch nicht so ganz trivial und von der Hand zu weisen. Denn wenn man genau hinschaut unterstützt FMX unter Windows nur eine

proprietäre Schnittstelle, ebenso unter MacOS. Danach wird es ganz ganz finster. Wobei das Thema Screenreader ohnehin nicht als Pro-Contra-Argument taugt, weil auch die VCL da nicht wirklich glänzt. Daher muss sich jeder von uns schon mal fragen lassen, ob man sich jemals ernsthaft bei den eigenen Projekten Gedanken um Blindentauglichkeit gemacht hat...

Prinzipiell mag es ja egal sein, ob man ein neues Projekt mit VCL oder FMX startet. Vorhandene VCL-Projekte aber auf FMX zu portieren dürfte aber einen größeren Aufwand mit sich bringen, selbst wenn das vorhandene Projekt ganz strikt nach MVP-Prinzipien gebaut ist. Genau darum drehte sich das Blogpost von McKeeth. Machen wir uns mal nix vor, Emba hat uns da mit den zwei inkompatiblen Frameworks ein ziemliches Ei gelegt. Denn dass es überhaupt nötig ist, sich zu Beginn für eines zu entscheiden und das dann für sehr lange Zeit in Stein gemeißelt ist, das ist ein Konstruktionsfehler seitens Emba.

**bra**

Zitat von jaenicke:

Wenn du so heran gehst, gibt es keine einzige Programmiersprache, die Cross Platform ist. Schließlich kannst du mit keiner unter x86 Prozessoren ARM-Code ausführen oder umgekehrt...

Doch, man kann z.B. Java-Byte-Code ohne Neukompilieren auf verschiedenen Plattformen ausführen *klugscheiss*

Ja, dazu braucht man dann die Runtime

**jaenicke**

Darum ging es aber nicht. Es ging darum, dass LowLevel-Zugriffe laut EWeiss und Fritzew plattformunabhängig sein sollen, damit das Framework plattformunabhängig ist. Java-Bytecode ist immer noch Hochsprachencode, nur in Zwischencodeform. Das heißt du hast da nicht (wie hier für Crossplatform nach diesem Verständnis gefordert) ARM- oder x86-Assemblercode plattformunabhängig in deinem Code geschrieben.

Das heißt wenn man den Faden weiterspinnt, müsste jede nach EWeiss und Fritzew echt plattformunabhängige Sprache automatisch ARM-Assemblercode auf x86 emulieren und umgekehrt, DirectX auf Android, usw.

**Fritzew**

Zitat von jaenicke:

Das heißt wenn man den Faden weiterspinnt, müsste jede nach EWeiss und Fritzew echt plattformunabhängige Sprache automatisch ARM-Assemblercode auf x86 emulieren und umgekehrt, DirectX auf Android, usw.

Nein es geht darum das wenn das Framework an seine Grenzen kommt und das tut es nun mal, es möglich sein muss weiterhin möglichst Plattform unabhängig zu bleiben.
Ganz einfach zb Opengl Code schreiben zu können auf allen Plattformen.
Im Moment musst Du Windows ganz anders behandeln als alles andere.
Was einfach fehlt ist die Opengl Unterstützung auf Windows. Haben Wir das bin ich ruhig.
Der 3D Teil von FMX ist für anspruchsvolle Sachen mit grossen Datenmengen nicht brauchbar. Versuche mal mit FMX mit Objecten die unterschiedlichen Texturen, Texturekoordinaten und Transparenzen zu arbeiten. Viel Spass

**Mavarik**

Zitat von Codehunter:

Machen wir uns mal nix vor, Emba hat uns da mit den zwei inkompatiblen Frameworks ein ziemliches Ei gelegt.

Man könnte auch sagen: Emba war klug genug - siehe kylix - nicht zu versuchen die VCL cross Plattform fähig zu versuchen, sondern sich getraut den alten Zopf ab zu schneiden.