Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ich denke mal, dass solche eine Direktive nur ein kleiner Tropfen auf den Sprichwörtlich besagten heißen Stein wäre. Das Problem in meinen Augen wären dann recht neue Extensions. Ich sage mal nur ARB_point_sprites. Find ich für Partikel irre praktisch. Und schon hat mal alle Extension im Schlepp. Bei dem Großteil der Extensions handelt es sich vor allem um ziemlich alte Extensions. Ich denke aber mal, wenn man kommuniziert, dass das Laden in .NET 1.1 langsam ist, dann sollte es schon gehen.
Ich persönlich finde einzelnes Laden von Extensions auch nicht so sonderlich praktisch. Im Endeffekt darf man nicht vergessen, dass .NET erst einmal auf dem Vormarsch ist. Also so groß dürfte die Anzahl der Entwickler dort auch noch nicht sein. Zur Not müssten dann die entsprechenden Entwickler halt die Extensions die sie nicht haben wollen selber auskommentieren.
Und die ganzen extern geschriebenen Bibliotheken. Ich denke mal nicht, dass die Entwickler dort sonderlich erfreut sind, wenn sie ihre Quellen ändern müssen. Ich wäre es nicht.
Was mir gerade einfällt. Evtl kann man es ja gestalten, dass man vorher abprüft ob eine Extension unterstützt wird und wenn ja nur dann werden die Methode geladen. Somit fallen auf Jedem System schon mal über die Hälfte an Extensions weg. ATI, NV. Ich bin ja sowieso dafür, dass die beiden Methoden ReaxExtensions und ReadImplementedProperties zusammengefallst werden. In etwa so.
Das Problem ist, dass manche Extensions nicht im Extension String enthalten sind, obwohl die Funktionen da sind und auch benutzt werden können.
Die Möglichkeit für die kleine Exe und und für .Net wäre, nicht ActivateRenderingContext zu benutzen und dann die Extensions über die entsprechenden Funktionen selber zu laden. Für alle anderen, die weiterhin ActivateRenderingContext benutzen bleibt alles wie bisher.
Eventuell kann man mal überprüfen, ob Delphi dann die nicht benutzten Funktionen rausläßt.
Das der Benutzer im Header selber Änderungen vornimmt ist nicht so gut, weil er das dann bei jedem Update erneut machen muß.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Nichts für Ungut aber Extensions die nicht im Extensionstring aufgefüht sind sollten auch gar nicht verwendet werden. Für Entwicklerzwecke mag das okay sein aber für alles andere gehört sich das nicht. Das wird schließlich auch einen Grund haben warum die nicht mit dabei sind. Im Endeffekt könnte man auch ein Define machen womit man dann das Laden von allen Methodenpointern erzwingen kann. Dann hätten wir aber wieder genau das Problem was wir jetzt auch haben. Und zwar das es einfach nur ewig dauert.
Der einzige Weg um die Größe und Geschwindigkeit sinnvoll kleiner zu gestalten ist aber die Extension einzeln ladbar zu gestalten. Um den resultierenden Code so kleiner wie möglich zu bekommen wäre das "Sinnvollste" alle Extension mittels Define abzugrenzen. Also würden nur noch Extensions existieren die auch wirklich definiert sind. Hätte den Vorteil, dass man die nicht mal mehr verwenden könnte. Aber davon halte ich nicht viel! Das macht das alles nur unnötig kompliziert. Ich würde es dann wohl eher so machen, dass man einen Methode pro Extension erstellt die dann entsprechend alle Pointer lädt. In der Methode ReadExtensions würden dann alle Methoden ein mal aufgerufen werden. Um es dem Rest so einfach wie möglich zu gestalten. Also so wenig wie möglich Umstiegsprobleme zu provozieren.
Zusätzlich würde ich es dann aber dennoch gerne sehen, dass man per Default nur die Extensions lädt die auch existieren. Das könnte man ja durch das angesprochene Define global aushebeln. Aber ich denke mal, dass es für 99,8% der Benutzer ausreicht, wenn nur die Extensions geladen werden die auch existieren.
Ich hatte das glaube ich auch schon mal erwähnt. Der Übersicht halber würde ich auch alle Zusatzfunktionen wie CreateRenderContext etc in eine Extra Unit auslagern. So etwas wie dglOpenGLUtils oder so. Damit hätte man mehr Übersicht und Anfänger könnten dann auch mal schneller nachschauen wie wir das gemacht haben. Dann müssen die sich nur durch den kompletten Header wurschteln.
Registriert: Sa Mai 04, 2002 19:48 Beiträge: 3827 Wohnort: Tespe (nahe Hamburg)
Vielleicht ist der Gedanke mit einer seperaten Unit gar nicht so abwägig? Man könnte evtl. versuchen dort weitere Initalisierungsfunktionen a la InitOpenGL12; anbieten. Wer die normalen Header verwendet und das bisherige Init aufruft hat alles wie gewohnt, wer gerne möchte, dass Extensions nur bis zu einer speziellen Version (Hersteller?) initalisiert werden, muss die Initalisierug über die anderen Funktionen abwickeln. evtl. eben dann auch einen Modus in dem man alle Extensions manuell einfügen kann und nichts von Haus aus eingebunden wird. Vielleicht red ich Blödsinn, weil ich den Aufwand nicht richtig abschätzen kann, allerdings wäre dies doch eine Möglichkeit ohne großen Umbruch des Systems (oder auf Gefahr hin, dass Newbs "umlernen" müssen) das Problem in den Griff zu kriegen.
_________________ "Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."
Mehrere Dateien finde ich nicht so gut, weil es ja logisch zusammengehört und die Leute das ja immer zusammen benutzen. Die paar Funktionen können auch noch in die Unit. Wenn man nicht alle Extensions laden will, nimmt man eben dann die einzelnen Funktionen und darf nicht ActivateRenderingContext benutzen. Das müßte für den Linker ausreichen, damit die Exe Datei kleiner wird. Außerdem sollte man deswegen nicht alles umstrukturieren. Die Leute die richtig kleine Demos schreiben verwenden sowieso ihre eigenen angepaßten Header. Das wirkliche Problem ist die Ladezeit unter .Net.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ich denke mal, dass so eine Gruppierung nach der Version keinen großen Sinn machen würde. Es ist ja auch so, dass man häufig gar nicht den gesammten Funktionsumfang bräuchte. Speziell, wenn man 1 - 2 OpenGL 1.5 Features (Point_sprites) benutzen würde, hätte man nichts wirklich gespart, weil er dennoch alles laden würde. Man könnte evtl die Corefunktionen als Extensions betrachten. Und zwar, dass man diese dann auch ähnlich einer Extension laden würde.
Ich wäre dann auch dafür, dass die Methode ClearExtension komplett raus fliegt oder benutzt die jemand von euch? Das würde den Header auch wieder ein wenig schlanker machen.
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.