VST: Neuer versuch gescheitert....

[Hitman]

Was genau macht Eigentlich lclextensions ?

Keine Ahnung. Ich weiss nur was hier steht, und das ist nicht viel : https://luipack.bountysource.com/wiki/lclextensions" onclick="window.open(this.href);return false;
Die vtv-unstable hat für meinen Geschmack ein bisschen viel Abhängigkeiten von anderen Paketen.

Alle benötigten Pakete sind von dem selben Entwickler. Er hat lediglich besser modularisiert. Finde ich jetzt nich so dramatisch. Außerdem ist der Link den du gegeben hast veraltet. Siehe mein vorheriger Post, da sind die aktuellen URLs. Die dort ausgecheckten Versionen kompilieren sogar mit der aktuellsten Lazarus Revision sowohl unter win32 als auch gtk2 (gerade eben getestet).

[theo]

Die dort ausgecheckten Versionen kompilieren sogar mit der aktuellsten Lazarus Revision sowohl unter win32 als auch gtk2 (gerade eben getestet).

Ich habe natürlich schon die SVN Versionen ausgecheckt. Der Link oben bringt nur ein bisschen Info über lclextensions.
Das Problem das ich beschrieben hatte bezüglich "pango_extents_to_pixels" hatte mit meiner Pango Version zu tun

http://mail.gnome.org/archives/gtk-app- ... 00199.html" onclick="window.open(this.href);return false;

[pluto]

Das ist mir schon klar... Warum ändern, wenn es so bleiben kann Aber was sollst. Diese VST Version ist jedenfalls nicht schlecht. Das ist eine Version die ich auch nutzten kann und werde. Da die VST doch recht viele Vorteile hat *G*

[Hitman]

Einziger Nachteil dieser VST Version ist, dass es für einige Sachen (Alpha Blending z.B.) unsinniger Weise Assembler verwendet ...
Einerseits ist es daduch nur i386 kompatibel, andererseits bin ich mir sicher, dass FPC aus nativem Pascal Code (mit entsprechendem Target Processor und Optimierungen) weitaus mehr rausholen kann. Vielleicht ändert sich das im Laufe der Zeit ja noch ... spätestens wenn ichs mal für x86_64 brauch, mach ichs dann selbst *g*

[pluto]

Ich dachte, Selbst geschriebener ASM code sollte schneller sein, als wenn es der Complier erzeugt. Ist das bei FPC, der Gegenteil ?

[Hitman]

Je nachdem .... aber da der asm code für i386 geschrieben ist, FPC aber selbst auf x86 Rechnern bis i686 plus einiger Befehlssatzerweiterungen wie SSE3, MMX, etc. pp reicht, kann der Compiler wohl deutlich bessere Befehle wählen als man das selbst kann. Klar, wenn du in der Lage bist, auch solche asm Befehle zu beherrschen, kriegst du vlt. ein etwas besseres Ergebnis hin als der Compiler ... aber ist es das wert? Von FPC will ich in erster Linie Portabilität. Optimierung im Millisekundenbereich kann ich dann an wirklich wichtigen Stellen berücksichtigen ... und da gehört die GUI nunmal nicht dazu.

[pluto]

Da hast du durchaus recht.....

[Christian]

Quark hat keine Gräten. (Da wir schonmal bei Thread zuspammen sind)

[pluto]

ich weiß jetzt wirklich nicht was deine Antwort mit den vorherigen Antworten zu tun haben könnte
Kann mir da jemand helfen. Das was Hitman stimmt doch....