Zitat von OlafSt:

Wenn die Anzeige 10x die Sekunde neu gezeichnet wird, dann ist das schon verdammt nah dran. Und das ist ein Neuzeichnen alle 100ms. Ich denke, 20fps würden mehr als dicke reichen, das sind 50ms zwischen den Redraws.

Nö das reicht nicht bedenke um so höher die Auflösung desto geringer die FPS..
Das mag bei einer Auflösung von 320x240 gehen aber nicht bei 1920x1200 oder drüber
Es bringt mir nichts wenn ich auf grund irgendwelcher einsparungen letztendlich mit dem Beat hinterher hinke..
Alles schon versucht.

gruss

Was genau zeichnest du da eigentlich und wie? Wenn du es mit DirectX oder OpenGL machst, sollte die Auflösung doch fast keine Rolle spielen...

Zitat von NamenLozer:

Was genau zeichnest du da eigentlich und wie? Wenn du es mit DirectX oder OpenGL machst, sollte die Auflösung doch fast keine Rolle spielen...

Mit was man zeichnet spielt keine rolle bei beiden DX und OGL ändert sich die FPS abhängig von der Fenster größe.

Siehst du doch bei spielen wenn man hier die Auflösung ändert.
Aber wie im Beitrag schon geschrieben geht es mir nicht um die FPS sondern darum
das ein Core mit Volllast fährt obwohl die CPU ansich nicht ausgelastet ist.

Arbeite dran

gruss

Zitat von EWeiss:

Zitat von NamenLozer:

Was genau zeichnest du da eigentlich und wie? Wenn du es mit DirectX oder OpenGL machst, sollte die Auflösung doch fast keine Rolle spielen...

Mit was man zeichnet spielt keine rolle bei beiden DX und OGL ändert sich die FPS abhängig von der Fenster größe.

Siehst du doch bei spielen wenn man hier die Auflösung ändert.

Aber nur bei graphisch sehr aufwändigen Spielen, ansonsten sind meist mehr FPS möglich als der Bildschirm darstellen kann. Dass das Rendern deines wie auch immer aussehenden Frequenzhistograms so aufwändig ist, dass es (auf der GPU) länger dauert als die FFT (auf der CPU), kann ich mir irgendwie kaum vorstellen, es sei denn, da ist irgendwas sehr ineffizient gelöst. Aber es ist halt schwer zu sagen, wenn man so wenig konkretes weiß. Wenigstens ein Screenshot um mal grob einen Eindruck zu bekommen, worum es eigentlich geht, wäre hilfreich...

Falls wirklich das Rendern auf der GPU der Flaschenhals ist, bringt dir jedenfalls auch Multithreading nichts.

Die GPU hat gerade mal 9% (vom gesamten System natürlich) die probleme macht die CPU ein Kern!

Weiss nicht was dir ein Bild jetzt sagt habe es aber mal angehängt.
Habe es in einem Archiv gepackt weil es sonst hier im Forum verkleinert wird.

gruss

für alle die wie ich darüber genervt sind/waren das archiv erst entpacken zu müssen... :

Zitat von glotzer:

für alle die wie ich darüber genervt sind/waren das Archiv erst entpacken zu müssen... :

Du Spassvogel!

Dir ist wohl klar das du nun die relativen Dinge um die es geht nun nicht mehr siehst?
Es hatte schon einen grund das ich es in einem archiv gepackt habe.
Die Auslastung der resourcen GPU/CPU usw.. kann man auf deinen Shot nicht mehr erkennen.

gruss

Zitat von EWeiss:

Weiss nicht was dir ein Bild jetzt sagt habe es aber mal angehängt.

Weil Bilder weniger missverständlich als Beschreibungen sind. Ist mir z.B. schon oft so gegangen, dass ich Leuten versucht habe, bei irgendwelchen Computerproblemen zu helfen und sie stundenlang per Messenger ausgefragt habe und wir völlig aneinander vorbeigeredet haben, und nach einem Screenshot war sofort klar, was Sache ist...

Zitat von EWeiss:

Die GPU hat gerade mal 9% (vom gesamten System natürlich) die probleme macht die CPU ein Kern!

Und das macht mich stutzig. Also wenn du sagst, dass das Rendern bei größerer Auflösung langsam wird, dann würde das bedeuten, dass die GPU der Flaschenhals ist, weil diese sich ja um das Rendern kümmert. Der CPU ist es ja egal, wie groß die Ausgabe der GPU ist, denn auf der CPU laufen unabhängig von der Auflösung immer die gleichen Befehle.

Aber da die GPU nur zu 14% (laut deinem Screenshot) ausgelastet ist, kann das nicht das Problem sein. Jetzt ist die Frage, was macht dein Programm bei höheren Auflösungen auf der CPU anders? Und welche Stationen durchläuft bei dir ein Frame genau, bevor es auf dem Bildschirm ausgegeben wird? Läuft das alles über OpenGL direkt? Oder – Gott bewahre – liest du etwa den OpenGL-Framebuffer mit glReadPixels aus, damit du das Gezeichnete mit der GDI weiterverwenden kannst?

Ich erstelle einen GDI-VideoBuffer(VisBuf) abhängig vom Viewport = bsp. 512x384 außerhalb des Threads.
Die Visualisierung wird dann also in VollBild 1920x1200 auf den Viewport 512x384 gestretcht.
Das schont CPU resourcen.

markieren

Delphi-Quellcode:

  FillChar(BmpInfo, SizeOf(BITMAPINFO), 0);
  BmpInfo.bmiHeader.biSize := SizeOf(BITMAPINFOHEADER);
  BmpInfo.bmiHeader.biWidth := StretchWidth;
  BmpInfo.bmiHeader.biHeight := -StretchHeight;
  BmpInfo.bmiHeader.biPlanes := 1;
  BmpInfo.bmiHeader.biBitCount := 32;

  VisBmp := CreateDIBSection(0, BmpInfo, DIB_RGB_COLORS, VisBuf, 0, 0);

Dann wird der Record VisData mit den Wave/FFT Daten gefüttert
und anschließend im Plugin selbst gerendert wo ich keinen Einfluss drauf habe

markieren

Delphi-Quellcode:

        if (not VisInfo^.VisPointer^.Render(VisInfo^.VisBuf, StretchWidth,
          StretchHeight, StretchWidth, @VisData)) then

anschließend hole ich mir das DC vom OpenGL Contex (RenderWindow)

DC := GetDc(ParentHandle);

Danach verwende ich StretchBlt um die Daten auf das DC vom Source VisDC zu zeichnen

markieren

Delphi-Quellcode:

        if (not StretchBlt(DC, VisInfo^.x, VisInfo^.y, VisInfo^.w, VisInfo^.h, VisInfo^.VisDC, 0,
          0, StretchWidth, StretchHeight, SRCCOPY)) then

Anschließend wird der inhalt vom VisBuf in eine OGL-Texture kopiert

markieren

Delphi-Quellcode:

        
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, StretchWidth, StretchHeight, 0,
GL_BGRA_EXT, GL_UNSIGNED_BYTE, VisInfo^.VisBuf);

Der rest sind noch ein paar OGL sachen

markieren

Delphi-Quellcode:

glEnable(GL_TEXTURE_2D);
glBegin(GL_QUADS);
...
glFlush();
SwapBuffers(glDC);

Das wars dann.

Nach meiner änderung von Timer auf Thread geht es jetzt soweit und die Kerne werden
gleichmäßig ausgelastet.
Wenn aber nun aus der Anwendung heraus die resitz Message geschickt wird die außerhalb des threads läuft

Result := BASS_SONIQUEVIS_Resize(Param^.VisHandle, Left, Top, Width, Height);

dann kracht es gewaltig in irgendeiner OGL .dll

so sieht es im moment aus.

Zitat:

liest du etwa den OpenGL-Framebuffer mit glReadPixels aus

Nein die Pixels werden in Rechtecke zerlegt aus der glTexImage2D Texture

zusammenfalten · markieren

Delphi-Quellcode:

        glColor4f(1, 1, 1, 1);
            glEnable(GL_TEXTURE_2D);
            glBegin(GL_QUADS);
              glTexCoord2d(0.0, 0.0);
              glVertex2f( 0.0, 0.0);
              glTexCoord2d(0.0, 1.0);
              glVertex2f( 0.0, LastHeight);
              glTexCoord2d(1.0, 1.0);
              glVertex2f(LastWidth, LastHeight);
              glTexCoord2d(1.0, 0.0);
              glVertex2f(LastWidth, 0.0);
        glEnd();

gruss