klar, API wird von der performance her besser sein, aber ich möcht mal wissen, wieviel % etwa?

Wir hatten darüber schon ein paar Threads.... Irgendwann hab ich angefangen in den VCL Code zu schaun und zu überlegen um wieviel langsamer VCL denn nun sein müsste - und sei beruhigt, es geht hier wohl kaum um ganze Procent, sondern höchtens um Promill => vergiss diesen Gedanken einfach und tu so als wären sie gleich schnell.

Jo, die Performance sollte man dabei defintiv außer acht lassen. Ich selbst befürworte die API, schlicht und ergreifend, weil ich da mehr das Gefühl habe, wie was genau bei einem Projekt abläuft. Weil man eben die Schleife mit allem drum und dran selbst verfaßt, daher bevorzuge ich bei Spielen etc. eher die API, für kleine Tests und Tools ist die VCL defintiv die bessere Wahl... ach ja, solange du die SysUtils nicht benutzt, die ist API Exe natürlich um einiges kleiner

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

huhu,

also im "normalen" leben benutzt ich nur die VCL... ich hab nochnie nen tool in NonVCL/API geschrieben.. *g* nurmal nen Formular mit Button drauf und so nen quatsch

Aber... bei OpenGL... da habe ich ausser meinem LevelEditor für Snake und TLoF nochnie mit VCL gearbeitet...
und würde diese doofe Textures Unit von JanHorn nich die Classes Unit benutzen wäre es komplett API *g*

Der grund dabei is im grunde einfach der, das ich es für ziemlich sinnlos halte einfach nen GrauesForm immer mitzuschleppen... ich meine, bei OpenGL wird in der regel eh nix auf dem Form gemacht... (ausser halt bei LevelEditor etc).

Au'revoir,
Aya~

?!? Wieso graues Form mitschleppen? Die Form wird immerhin für die OpenGL-Ausgabe verwendet und man kann noch die Netten OnResize, OnKeyDown, OnKeyPress, OnKeyUp, OnMouseDown, OnMouseMove, ... etc. Ereignisse verwenden! Außerdem gäbe es da noch on Aktivate und OnDeactivate, mit deren Hilfe das Rendern im Falle dass die Form den Fokus verliert, pausiert werden kann.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Mit der reinen API kann man genauso performanceschwach programmieren! Es kommt immer ganz auf den Menschen an der da hinter sitzt.

Der Streit API<->VCL wird nie ein Ende nehmen. Allein daran sieht man schon, dass es nicht wirklich unterschieden zwischen den beiden giebt. Und das Argument "ist kleiner" ist in der heutigen Zeit wirklich 'n Scherz. Den das meiste was die Größe angeht sind wohl die Modell und Textur-Daten. Also was soll der Geiz. Wenn ich das an FF8 für den PC denke. Die EXE hatte über 20 MB!!!

Die meisten Games habe große EXEs, denn das was man als kleine EXE sieht ist in wirklichkeit nur der Loader der nach der OriginalCD schaut (Kopierschutz) und dann die eigentliche EXE die anders heißt aufruft. Letztere ist dann eben auch entsprechend groß. So bekomme ich das auch hin: Eine starter exe mit 40 KB und eine eigentliche EXE mit dem Namen z.B.: Main.gam und vóila. Außerdem spricht eine kleine EXE nicht für effizienz in der Ausführung. Und für die Harten fälle gibt's immer noch UPX.

Wenn ich da z.B. an Unreal2 denke: 3 GB auf der Platte! Was juckt da noch die Größe der EXE? Aber genaugenommen sind die 3 GB ja irgendwie unverschämt... <_<

(Sorry Aya, nicht persänöich nehmen

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Aber wie Delphic bereits mal festgestellt hat: Soviel Nachrichten-Müll wird von der VCL gar nicht verarbeitet. Somit macht die VCL im groben und ganzen auch nichts anderes als Du in Deiner Schleife. Ok, mag sein das Deine Schleife nur das aller aller notwendigste macht und dadurch 3 Tackt-Zyklen weniger benötigt. Aber das reißt's nicht wirklich 'raus. Und der "Datenmüll" den Delphi durch die VCL 'reinlinkt macht das Programm auch nicht langsammer, denn Delphi ruft doch keinen Code auf der nicht benötigt wird nur weil er, warum auch immer, in der EXE ist!

Hier ein Code-Sample aus der VCL von Delphi 7 (Borland möge mir verzeihen ):


Das passiert, wenn Du Application.ProcessMessages aufrufst. Und sorry, aber arg viel anders als Deine Funktion ist auch nicht drinnen. Und die paar If-Abfragen und Message-Auswertungen kann man wirklich vernachlässigen. Im Gegenzug dazu bekommt man eben entsprechenden Komfort was die Abfrage von Maus und Tastatur-Ereignisse der Form angeht.

Also IMO muss man nicht an der Schleife anfangen zu optimieren, sondern an seinem Restlichen OpenGL-Code, Oc- oder BSP-Tree oder was auch immer. Das, was an Taktzyklen bei der VCL im Gegenzug zur API "verschwendet wird" kann man wirklich ignorieren.

Ach ja, nochmal zum Datenmüll: Es ist einfach leichter per TBitmap oder TJPEGImage eine Textur zu laden. Es ist einfacher, mit Hilfe von TINIFile seine Optionen zu laden und zu sichern ect... Das Rad aus Lernzwecken neu zu erfinden ist eine sache. Wenn ich aber schon ein paar nette Tools von Delphi hab', warum nicht verwenden. Nur aus Angst, mein Prog wird langsammer? Na, dafür sich einen solchem Mehr-Stress zu geben, ob sich das lohnt?!? Immerhin arbeiten wir nicht mehr mit 100MHz-Kisten. Und spätestens dann, wenn Du mit Multithreading arbeitest, wirst Du das ein oder andere Einbinden müssen.

Schau Dir doch mal die Demos von GLScene bzw. mit GLScene erstellte Programme an. Die laufen gut und arbeiten nur mit VCL. Das Demo mit dem Animierten Character (MD2-Format) arbeitet nicht mal mit 100% Prozessorauslastung (auch wenn ich keine Ahnung hab', wie die das machen :unsure: ). Aber langsamm wegen VCL ist wirklich nicht das Thema.

Aus diesen Gründen bin ich der Meinung, dass die VCL gegenüber der API nicht wirklich Nachteile hat. Wer natürlich seinen Source auch für FreePascal offen halten will, muss auf die VCL und deren "goodies" größtenteils verzichten.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

@MD2: Ok, wie bitteschön bekommt man das hin, dass das Prog nicht mit 100% Prozessorauslastung arbeitet?!?

@Syncro: Ok, hier bin ich mir nach ganz sicher, aber IMO benötigt man für die Grafik-Ausgabe mit OpenGL kein Syncro. Kann mich aber auch irren (wäre bescheiden, wenn's anders wäre).

@Rest: Hmm... das bringt mich auf eine Idee. Melde mich in ein paar Tagen wieder zu dem Thema. Muß mal was testen...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Also du musst OpenGL definitiv nicht synchronisieren. Das Läuft vollkommen und ohne Probleme in dem anderen Thread ab. Du musst auch nicht einmal MakeCurrent aufrufen (außer beim Initialisieren).


Du hast nen Timer zum rendern verwendet? *kopfschüttel*


Dann hast du aber noch keine richtig komplexen Anwendungen geschrieben. Da kommst du nämlich in Teufels Kücke wenn du ohne so etwas auskommen willst!


Aber jetzt mal zu dem anderen. Ist das nicht alles irgendwie nur ideologisch? Es ist doch vollkommen egal was man verwendet!
Ich persönlich bin Faul und schwöre auf OOP und aus genau diesem Grund verwende ich die VCL. Spätestens dann wenn dort 3 oder 4 Dialoge mit hinzukommen wird es etwas schwieriger ohne VCL auszukommen.

Was ich für viel wichtiger erachte ist doch die Tatsache was der Entwickler dann daraus macht! So lange ich den Rest meines Programmes genügend optimiere (Speicherauslastung, Rechenbedarf) kann ich locker die VCL verwenden. Das nehmen sich aber leider nicht alle Programmierer zu herzen!

Gut, ich habe hier einen 486 DX-50 rumstehen mit 2D PCI VGA Grafikkarte- bitte bringe darauf, dein letztes grösseres 3D Projekt(sagen wir mal 50.000 Polygone per frame sichtbar) in ansprechender Geschwindigkeit zu laufen - ich verrate dir eines: Du wirst es nicht schaffen und daran ist mit sicherheit nicht die VCL schuld, denn auf diesen Systemen ist die VCL immernoch schnell genug, so dass sich eine "optimierung" auf API gar nicht lohnt. Du wirst damit nicht 1 mickriges Prozent herausschlagen können. Der API Effekt ist zwar da, aber einfach zu gering um überhaupt nur drüber nachzudenken. Alle anderen Algorithemn in deinem Programm sind da viel wichtiger.


Aber hoppla... Synchronisation hat ganz viel mit Multithreading zu tun - auf 1 Prozessorsystemen tatsächlich wenig, aber sobald da ein 2.er Prozessor hinzukommt geht ohne Synchronisation rein gar nichts mehr. Die Beiden Prozessoren kommen sich ständig ins gehege, wenn sie mit gleichen Speicherbereichen arbeiten - und das ist hier ja wohl der Fall. Synchronisation ist also nicht nur eine Abhilfe, sondern auf solchen Systemen die Möglichkeit schlechthin(wie auch immer sie von statten geht). Auf 1 Prozessor System gibts sicher mittel und wege das zu umgehen, da nie zwei Threads gleichzeitig laufen können, was aber auch bedeutet, dass du auf einem solchen System kein echtes multithreading hast.