Qt langsamer als direkte Win-API-Programmierung?

[katana]

Hallo,

ich bin neu im Qt-Feld. Ich habe ein altes Programm in Qt neu geschrieben, welches ich urspruenglich direkt mit der Win-API programmiert hatte. Das Programm besteht aus zwei Fenstern, ein kleines mit ein paar slidern um Parameter einstellen zu koennen und ein grosses um Daten, die aus den Parametern berechnet wurden, darzustellen (in diesem Falle eine Zeitreihe).
Die urspruengliche Win-API-Version ist sehr schnell - ich kann einen Parameter rumschieben und sehe sofort die neuen Daten. Bei der Qt-Version ist jedoch eine deutliche verzoegerung spuerbar. Koennte das an der Art und Weise (signals und slots) liegen, wie Qt die slider mit dem Hauptfenster verbindet? Weis jemand etwas genaueres zu Qt und Performance?

[BartSimpson]

Das liegt ja auf der Hand, da bevor es zu den nativen Aufrufen geht, muss es ja erst mal durch das Qt System. Dafür kannste aber auch dein Programm unter fast jedem OS laufen lassen.

[Christian81]

Ausserdem kommt es drauf an wie es in Qt implementiert wurde - man kann vieles so programmieren dass es langsam ist...

[Tarek]

Falls du mit MinGW kompiliert hast liegts bestimmt daran, das Teil ist quälent langsam. Probiers mal mit dem VC-Compiler, rein vom Gefühl her laufen Programme damit nicht langsamer als mit Win32-API oder MFC, zumindest nach meiner Erfahrung, und das sollte auch so sein denn so groß ist der Qt-Overhead ja schließlich gar nicht.

[katana]

Ich kompiliere mit VC. Ich bin auch davon ausgegangen, dass ich vielleicht irgendetwas falsch implementiert habe, so dass es viel langsamer laeuft als moeglich.
Andererseits ist das Programm so simpel, dass man da eigentlich gar nicht viel falsch machen kann.
Das Programm besteht im wesentlichen aus 'nem slider der ein update() des anderen fensters ausloest, so dass die daten neu berechnet und dargestellt werden. Die Neuberechnung findet auch mit in paintEvent() statt, so wie auch schon bei der alten API-Version.

Ich dachte vielleicht gibt es schon sowas wie Benchmarks oder geneauere Angaben, was fuer Prozesse oder Kombinationen von Widgets tendentiell viel langsamer sind als bei einer direkten Programmierung.

[Christian81]

Auch im paintEvetn kann man viel falsch machen - so wie es sich anhört berechnest Du dort immer alles - dies würde ich aber im Slider-update machen und dann im paintEvent wirklich nur zeichnen.

[katana]

Ok, so was hatte ich auch noch vor.

Hab jetzt aber noch ein neues noch viel merkwürdigeres Problem.
Ich versuche gerade einen Editor für Audiodaten zu schreiben. Hab einfache QApplication-Beispiel mit Menu und Textfeld genommen und das Textfeld durch eine eigene Klasse ersetzt. Die Klasse kann im Moment Dateien laden, die einfach in qint16-Arry gelesen werden. Das Array wird dann gezeichnet. Zusätzlich habe ich das Fenster mit scrollbars ausgestatt, so dass ich die Daten hin- und herschieben kann. Dazu benuzte ich kein QScrollArea, sondern habe das Widget direkt mit Scrollbars ausgestattet, die ich im resizeEvent() entsprechend verschiebe und deren valueChanged-signal ich mit einem Slot verbunden habe in dem ich lediglich den offset der Daten neu setze und dann ein update auslöse.
Jetzt das merkwürdige: bei machen Datei funktioniert alles superschnell, so wie man es erwartet und von anderen Applikationen kennt. Bei anderen Dateien ist das Scrolling jedoch extrem langsam. Sobald man irgendwas verschiebt, dauert es fast ne Sekunde bis die Änderung sichtbat wird. Hier wird nichts berechnet nur die Daten auf den sichtbaren Bereich gezeichnet.
Das tritt auch immer bei den gleichen Dateien auf und ist auch unabhängig von deren Größe.
Weis jemand rat oder soll ich mal den Code posten?

[Tarek]

Versuch mal repaint() anstelle von update() zu benutzen, laut Dokumentation findet nämlich aus Gründen der Optimierung bei update() das tatsächliche Neuzeichnen erst nach der Rückkehr in die Hauptschleife statt wohingegen repaint() zum sofortigen Aufruf von paintEvent() führt.

Falls das nicht hilft solltest du auf jeden Fall mal etwas Quelltext posten.

[katana]

Versuch mal repaint() anstelle von update() zu benutzen, laut Dokumentation findet nämlich aus Gründen der Optimierung bei update() das tatsächliche Neuzeichnen erst nach der Rückkehr in die Hauptschleife statt wohingegen repaint() zum sofortigen Aufruf von paintEvent() führt.

Das hab ich auch schon probiert - aendert nichts. Hat vielleicht schon mal jemand etwas aehnliches programmiert (also ein Programm was einfach daten plottet), was ich mir einfach mal anschauen kann. Ich schau mal in wie weit sich der Qellcode meines Programmes reduzierlen laesst, so dass ich ihn hier posten kann.

[webmaster1987]

poste doch einfach mal deinen code vieleicht kann dann einer licht in die sache bringen