proggen.org

Ich stehe momentan vor dem Problem, das ich für die Grafikengine meines CAD-Programmes die Schnittstelle Implemntieren muss, ich aber nicht weis welches der 2 Verfahren ich nutzen soll:
Entweder Direkt einprogrammierte Grafikprimitiven (Linie, Ellipsen(/Kreis)Bogen) und dann alles Komplexere auf den höheren Anwendungsebenen (CAD-Engine, User-Interface) als Definition und Relationen zueinander Definiere, was abstriche in der Performance gibt, dafür aber mehr Flexibilität, Dynamik und Stabilität oder
das ich ein generisches Interface aufbaue, wodurch ich dann "Spezialfälle"(Viereck, Quadrat, Kreis Ellipse, etc.) direkt in der untersten Anwendungschicht Realisiere, was mir mehr Geschwindigkeit gibt, aber weniger Flexibilität.
Weil ich mich selbst nicht entscheiden kann, würde ich mich freuen, wenn ihr das ganze Kommentiert und/oder andere Wege aufzeichnet, wenn ihr welche habt.

MfG cloidnerux.

Es stellt sich doch nicht die Frage, ob Du eine Schnittstelle programmierst oder nicht, sondern ob Du der Schnittstelle zur Grafikkarte zusätzliches hinzufügst.

Zumindest unter OpenGL sind Vierecke und Quadrate keine Spezialfälle. Kreise und Ellipsen sind zumindest in GLU enthalten. Bleibt die Frage, was "etc." ist und welche Flexibilität Du benötigst.

Es stellt sich doch nicht die Frage, ob Du eine Schnittstelle programmierst oder nicht, sondern ob Du der Schnittstelle zur Grafikkarte zusätzliches hinzufügst.

Nur Indirekt, da ich die Schnittstelle zur Grafikkarte schon Abstrahiert habe und ich gerne entweder auf so wenige Primitiven wie möglich zurück will.
Weil es später im Programm dazu kommen kann, der der Nutzer aus einem Viereck ein Dreieck macht und ich mir gerade selbst die Antwort geliefert habe, die ich davor nicht gesehen habe...
Es ist nur schwer möglich, mit einem Generischen Interface im nachhinein aus einem Viereck ein Dreieck zu bauen, da ich dazu erstmal wieder den Grundtyp des Generischen Objektes heruasfinden müsste und dann für jeden Fall eine eigene Konvertierung starten zu müssen.
Daher werde ich die Grafikschnittstelle auf Linien und Bögen beschränken.

Zumindest unter OpenGL sind Vierecke und Quadrate keine Spezialfälle. Kreise und Ellipsen sind zumindest in GLU enthalten. Bleibt die Frage, was "etc." ist und welche Flexibilität Du benötigst.

Flexibilität hätte ich gerne so viel wie Möglich, da sich viele Komponenten des Programms auch super für andere Zwecke nutzen lassen und ich keine lust habe, den Code wieder umzuändern, nur um ihn für andere zwecke nutzen kann.

Ich denke, Programme sollte man daran ausrichten, was man als Maschine hat.

Schnittstellen, die gleichzeitig auch Adapter zwischen virtueller Maschine (Deine Schnittstelle) und echter Maschine (die Grafikkarte/Grafik-Library) kosten eben Zeit. Deswegen würde ich die Schnittstelle eigentlich so halten, dass sie möglichst wenig die Daten anpackt.

Schnittstelle eigentlich so halten, dass sie möglichst wenig die Daten anpackt.

Naja, es ist schon etwas komplizierter. Im Grunde habe ich keinen direkten Zugrif mehr auf die Grafikschnittstelle, sie ist schon durch eine Klasse Abstrahiert. Dann kommen weitere Objekte, die die Grafikprimitven repräsentieren und nur noch auf die Schnittstellen der Grafikengine zugreifen, dann kommt erst die Schnittstelle die mich Interessiert, nämlich die Verbindung des GrafischenObjektes mit dem CAD-Objekt, das mehrere Grafikprimitven und Relationen verwaltet, die vom User eingegeben wurden. Also ist es nur noch ein Adapter zwischen 2 "Virtuellen Maschinen". Was mir aber auch Punkte in der performance bringen kann, was zumindest die Grafik angeht, denn ich kann so die einzelnen Grafischen Objekte in einem Thread verwalten, während die Objekte ganz normal weitergezeichnet werden.