Zitat von Phoenix:

Willkommen in der schweren, steinigen Welt des Multithreadings

Also mit anderen Worten, das Rendern selbst im Plugin findet gar nicht mit OpenGL statt? Was ich jetzt nicht verstehe: Wozu verwendest du überhaupt OpenGL?

Ich bin jetzt nicht gerade als Freund von UML bekannt, habe mir jetzt aber trotzdem mal die Mühe gemacht, ein Sequenzdiagramm von deinem Ablauf zu machen, so wie ich ihn verstehe.

So wie ich das sehe, ist OpenGL bei dir völlig redundant, da du nur 1:1 die Daten auf den Bildschirm ausgibst, die du vorher schon auf der CPU berechnet und gezeichnet hast. Du blittest sogar das gleiche zwei mal, indem du erst mal mit der GDI die Visualisierung auf das OpenGL-DC zeichnest, und dann noch mal mit OpenGL selbst als texturierter Quad.

Die ganze Arbeit macht bei dir die CPU, durch die Verwendung der GPU erhöhst du hier nur den Overhead und machst das ganze langsamer.

Sorry, wenn ich es missverstanden habe, aber so erschließt es sich aus deinem letzten Beitrag.

Zitat:

Also mit anderen Worten, das Rendern selbst im Plugin findet gar nicht mit OpenGL statt?

Ja und nein.

Zitat:

Du blittest sogar das gleiche zwei mal, indem du erst mal mit der GDI die Visualisierung auf das OpenGL-DC zeichnest, und dann noch mal mit OpenGL selbst als texturierter Quad.

Ja gerade deshalb um die CPU zu schonen.
Ob ich nun den Viewport 512x384 also gestretcht auf die weite von 1920x1200 render
oder einen im format 1:1 macht schon einen riesen unterschied.

Das gestretche Format wird dann natürlich auch in OGL übernommen.
Das ist bedingt durch die Plugins selbst weil diese eigentlich für ein Bildformat von 512x512 ausgelegt sind.
Die Leute wollen aber VollBild.

Zitat:

Die ganze Arbeit macht bei dir die CPU, durch die Verwendung der GPU erhöhst du hier nur den Overhead und machst das ganze langsamer.

Bedingt vielleicht..
Ist auch eine frage der Ansicht ob ich nun einen schriftzug in OGL Render oder einen in GDI macht doch schon einen recht großen Unterschied.
Zumal über BitBlt dieser dann auch noch in die Renderscene mit eingebunden wird (GDI)und das will ich nicht.
Da dies bei OGL-Plugins unansehnlich aussieht.

Zwischen Bass.dll und Plugin käme dann noch mein Wrapper und darum gehts

gruss

Zitat:

Du blittest sogar das gleiche zwei mal, indem du erst mal mit der GDI die Visualisierung auf das OpenGL-DC zeichnest, und dann noch mal mit OpenGL selbst als texturierter Quad.

Drüber war eine falsche Aussage!
Nein Blite nur dann wenn GDI verwendet wird ansonsten über texturierte Quads
Natürlich trotzdem gestretcht abhängig vom Viewport.

Bin jetzt soweit das es funktioniert.

gruss

Zitat von EWeiss:

Ja gerade deshalb um die CPU zu schonen.
Ob ich nun den Viewport 512x384 also gestretcht auf die weite von 1920x1200 render
oder einen im format 1:1 macht schon einen riesen unterschied.

Das gestretche Format wird dann natürlich auch in OGL übernommen.
Das ist bedingt durch die Plugins selbst weil diese eigentlich für ein Bildformat von 512x512 ausgelegt sind.
Die Leute wollen aber VollBild.

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.

Wenn dann müsstest du dir das StretchBlt schon sparen, dann würdest du wenigstens das Skalieren von der CPU auf die GPU verlagern. Aber selbst dann würde ich noch bezweifeln, dass das den Overhead von OpenGL rechtfertigt, denn: Die Bitmap-Daten werden, bevor sie an die GPU gelangen, mehrfach im Speicher herumkopiert, und dann müssen sie auch noch über den PCI-Port wandern, der ein berüchtigter Flaschenhals ist.

Faustregel: Generell ist es immer extrem langsam, irgendwas von der CPU auf die GPU zu transferieren oder umgekehrt.

Ich würde mit dir wetten, dass, wenn du OpenGL komplett rausschmeißt, du ein schnelleres Programm kriegst. Oder zumindest eines, das leichter zu warten ist und gleich schnell ist.

Und danach könntest du vielleicht über Multithreading nachdenken. Aber auch Multithreading ist, ebenso wie OpenGL, kein Silver Bullet.

Zitat:

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.

Nein habe es doch über deinen Beitrag berichtigt.
Und Multithreading funktioniert auch mit OpenGL

gruss

Zitat von EWeiss:

Zitat:

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.

Nein habe es doch über deinen Beitrag berichtigt.

Aber das Plugin rendert immer in VisBuf, oder? Ich weiß nicht so recht, was ich unter deinem „Ja und Nein“ zu verstehen habe. Zumindest steht es so im Code, den du gezeigt hast.

Hast du denn mal gemessen, ob es mit OpenGL wirklich schneller ist als nur mit der GDI?

Zitat von EWeiss:

Und Multithreading funktioniert auch mit OpenGL

Ja, aber spaßig ist es nicht gerade. Bevor ich mich da ins Gefecht stürze, würde ich mir lieber überlegen, ob das wirklich ein guter Ansatz ist.

Zitat:

Hast du denn mal gemessen, ob es mit OpenGL wirklich schneller ist als nur mit der GDI?

Es geht um das Aussehen deshalb habe ich OGL addiert.

Hab das Beispiel angehängt.. allerdings ohne Quelltext von BassVis
Quelltext der Anwendung selbst ist dabei.

Wenn man die Exe ausführt kann man den Unterschied sehen von OGL und GDI.
Doppelklick auf das Panel dann gehts ins Vollbild mit den eingestellten Vollbild Mode.
Denke das andere ist selbsterklärend.

Ein Kern sollte jetzt nicht mehr voll ausgelastet sein.
Den Viewport muss man von Hand im Code ändern hab da id der GUI nix addiert
dieser sollte aber im Format 4:3 sein

Anhang gelöscht.

gruss

Funktioniert bei mir lieder nicht, gleich zu Anfang kommt die Meldung „Cannot start default recording device!“. Liegt aber wohl an meiner Soundkarte, die blöderweise kein Loopback kann...

Zitat von NamenLozer:

Funktioniert bei mir lieder nicht, gleich zu Anfang kommt die Meldung „Cannot start default recording device!“. Liegt aber wohl an meiner Soundkarte, die blöderweise kein Loopback kann...

geht schon das auskommentieren.

markieren

Delphi-Quellcode:

{
  if (not BASS_RecordInit(-1)) or (not BASS_Init(-1, 44100, 0, Handle, nil))
    then
  begin
    BASS_RecordFree;
    BASS_Free();
    MessageDlg('Cannot start default recording device!', mtError, [mbOk], 0);
    Halt;
  end;
}

allerdings kannst du dann nicht über Device rendern.
geht eh nicht hab da noch was vergessen in der bassvis kommt davon wenn man sich nur auf eins konzentriert

gruss