Klassendesign für Multi-Render Engine

[Furtbichler]

Vielleicht sollte man doch aus Performancegründen eine Canvas-Fassade erstellen, die alle nötigen Grundfunktionen bereitstellt, wovon es ja nicht so viele gibt.

Damit wäre die Schnittstelle geklärt: Die Parameter sollten in Strukturen/Klassen übergeben werden, um diese erweitern zu können, ohne die Canvas-Schnittstelle anfassen zu müssen.

Die Fassade ist etwas monolithisch und geht in Richtung God-Class, aber ich kann mir vorstellen, das man das einerseits verkraften kann (ist ja eh nur eine leere Hülle ohne Funktion) und muss (Performance).

Man kann diese ICanvas-Interface ja auch explizit für jede Grafik-Engine umsetzen, wie man lustig ist.

Also: Entweder eine Canvas-Klasse und dahinter die Verzweigung in die einzelnen Grafiklibraries, oder für jede Lib/Engine eine eigene Implementierung.

Zitat von Zacherl:

...die allerdings den Nachteil hat, dass ich in der Darstellung der Komponente sehr eingeschränkt werde. Ich könnte beispielsweise keine DirectX11 sepzifischen Effekte aufrufen, ohne zusätzlich die abstrakte Render Klasse um entsprechende Funktionen zu erweitern (die dann für alle anderen Frameworks sinnlos wären).

Ich fände es eher sinnlos, wenn Controls in den unterschiedlichen Renderen unterschiedlich aussehen.

Man kann ja wohl jeden Effekt in jeder Implementierung emulieren, oder?

PS: Wie willst du das eigentlich umsetzen, wenn Du in DirectX11 einen SuperDuper-Effekt aufrufst, aber für die anderen nicht? Wo soll die Verzweigung denn sein? In deiner Paint-Methode? Oder willst Du die Logik des Zeichnens (was ja nicht ganz ohne ist) in jeder spezifischen Painter-Methode individuell umsetzen?

Wenn man zusammenfasst und abstrahiert muss man alles über einen Kamm scheren. Entweder nimmt man den kleinesten gemeinsamen Nenner, was dann zu einer ziemlich unpotenten Krücke wird, oder man orientiert sich an ein paar Fancy-Gimmicks, die nicht überall unmittelbar verfügbar sind. Alpha-Blending z.B. kann man wunderbar per Hand emulieren, ebenso antialiasing und diverse andere Effekte: Das das vielleicht langsam wird, ok. Aber das kann man immer noch optimieren.

[blackfin]

Wenn du für jede unterstützte Grafikschnittstelle von vornherein alle möglichen Besonderheiten und Möglichkeiten unterstützen willst und diese evtl. sogar iim Programmcode der Applikation selbst "switchen" willst, kann das auch ziemlich in der Sackgasse enden, da man die Übersicht verliert und der eigentliche Programmcode von Branches zugemüllt wird.

Ich würde das wohl eher in zwei Schritten machen:

1) Erst einmal den "kleinsten gemeinsamen Teiler" aller Grafikschnittstellen ermitteln, für alle Primitive und "Objekte", die du unterstützen willst und setzt diese auf die am effizientesten mögliche Art und Weise in separaten Klassen um, die nach aussen jedoch eine konsistente API an die Wrapper-Klasse / deine Engine liefern, z.B. eben Routinen wie DrawPolygon DrawRect oder Subklassen wie new FragmentShader etc.

2) Hast du diese implementiert und bekommst schon mal auf allen Schnittstellen ein ähnliches Bild, dann kannst du die entsprechenden Draw-Routinen für
jede Schnittstelle individuell auch noch mit Schnittellen-spezifischen Befehlen aufhübschen oder erweitern.

Anders machen es die "großen" Engines auch nicht, es wird für jede Schnittstelle einfach das "Ziel" individuell in den Low-Level-Routinen / Klassen umgesetzt, der eigentliche Spiele- / Applikationscode nutzt jedoch einen Layer darüber, der über Interfaces arbeitet, die sicherstellen, dass nach aussen die API für alle unterstützten Schnittstellen exakt gleich ist.

Das hat auch den Vorteil, für die Zukunft auch zusätzliche Grafikschnittstellen einbinden zu können, ohne dich beim Programmcode mit der eigentlichen, darunterliegenenden Schnitstelle befassen zu müssen oder Code am Programm selbst ändern zu müssen.
Willst du z.B. so etwas wie Mantle später unterstützen, baust du dir dafür "einfach" (haha!) eine Klassenstruktur, die deine Engine-API abbildet und du musst nichts am Programm selbst ändern.

Die Grafikschnittellen-spezifischen Optionen würde ich eher nutzen, um entweder performance-technisch die ein oder andere Schnittstelle zu optimieren oder um einige Sachen einfach "schöner" als in der anderen Schnittstelle erscheinen zu lassen.
Z.B. sagt dein Programm nur "new Snow()" o.Ä. Wie der Schnee dann aber aussieht und welche Schnittstellen-spezifischen Effekte er benutzt, kannst du in der eigentlichen Klasse schreiben, die direkt auf die Grafikschnitstelle zugreift.

[Zacherl]

Danke euch für eure Antworten Denke, dann weiß ich jetzt erstmal, welche Richtung ich hier einschlagen sollte.