[gelöst]Timer zu langsam

[Nash]

Hallo Leute,
ich möchte in einem Widget was rendern, lassen doch ist der Timer dafür meines erachtens zu langsam(trotz startTimer(0);),
wenn ich ganz normal im windowmode in einem renderloop etwas rendere, dann bekomme ich in meiner Testscene etwa 330FPS, render ich in ein widget, mit Hilfe eines Timer ,komme ich so auf 110FPS.

Gibt es eine schneller möglichkeit in ein widget in qt zu rendern?

[upsala]

Mal davon abgesehen, wie du visuell 110 von 330 fps unterscheiden willst, welches Betriebssystem verwendest du?

[Nash]

ganze einfach einmal rendere ich die Szene in windowed Mode.
wo ich einen einfachen renderloop habe.
Die Application ist dann ohne QT.

und einmal rendere ich das über einen timer in ein QMainWindow.
exakt die selbe Szene.

OS: WinXP

Die Frage ist verwendete man einen Timer um solche Sachen zu animieren?
vielleicht verwendet man ja threads, oder sowas, oder es gibt noch eine andere Möglichkeit.

[upsala]

Note that QTimer's accuracy depends on the underlying operating system and hardware. Most platforms support an accuracy of 1 millisecond, but Windows 98 supports only 55. If Qt is unable to deliver the requested number of timer clicks, it will silently discard some.

[Nash]

und das heißt jetzt? es liegt nicht am timer, schneller geht es nicht?

[upsala]

Genau

[Nash]

naja, mhm es muss eine möglichkeit geben.
hab die szene(oder das Modell besser mal gesagt) auch im 3ds Max viewport mir angeschaut, da komme ich so auf 250fps.
was recht gut ist und um einiges besser als der QT timer, vielleicht in einem thread auslagern...

[upsala]

Ich frag mich immer noch wie du 110 und 250fps unterscheiden willst. Ich bin zwar nicht mehr der jüngste, aber ich denke nicht, daß deine Augen so viel schneller sind... (Vom Monitor mal abgesehen)

[Nash]

hä?
klar macht das im endeffekt keinen unterschied aus, aber wenn ich sehe, das ein anderes Program mein Objekt nocht schneller Rendern kann, dann will ich das das genauso schnell ist.
und wir reden ja hier nicht von einem unterschied von 10-20 fps
sondern 150fps-200fps

[Christian81]

Ich würde einfach sagen QTimer ist für sowas ungeeignet. Ein Thread rendet und schickt das fertige Bild an den Mainthread - und der stellt dar. Dazu gibt es sogar ein schönes Beispiel in den examples (Mandelbrot denke ich, auf alle Fälle unter dem Stichwort 'Threads')

[upsala]

Könnte es sein, daß die andere Anwendung schnellere Zeichenroutinen hat, als deine?

[Nash]

nein, es liegt an qt

Ein Problem von Qt liegt in seinem Konzept der Ereignisverwaltung. Leider verwendet Qt
eine globale Ereignisliste, die nur von einem einzelnen Thread bearbeitet werden kann. Dies
ist insofern problematisch, weil sich der gleiche Thread auch für die Erzeugung sowie die Aktualisierung
der Oberfläche und damit für das Rendern der Szene verantwortlich zeichnet.
Erschwerend kommt hinzu, dass nur derjenige Thread einen OpenGL Kontext verwenden
darf, der selbigen erzeugt hat. D.h. es gibt in Qt einen Thread, welcher das OpenGL Fenster
und dessen OpenGL Kontext erzeugt, die Benutzeroberfläche verwaltet und zudem die
Szene rendert. Als Konsequenz können niedrige Frameraten bei der Ausgabe einer Szene zu
Blockaden der Oberfläche führen. Auch der Einsatz der Klasse QTimer zur getriggerten Visualisierung
in regelmäßigen Zeitabständen bietet nicht die eigentlich gewünschte Multithread
Lösung, da QTimer nach einem Zeitscheibenverfahren Rechenzeit von dem Ausgangsthread
abzweigt

Quelle:

http://deposit.ddb.de/cgi-bin/dokserv?i ... 15978x.pdf

[Christian81]

Ich habe doch nun aufgezeigt wie es geht... tztz als ob man gegen eine Wand redet

[Nash]

ohh sorry deinen Beitrag hab ich überlesen.
du hast inzwischen bestimmt ein ganz komisches Bild von mir
Ich schau mir das Beispiel gleich mal an.

btw, stimmst du mit dem Zitat überein?

[Christian81]

Imho bezieht sich das Zitat auf Qt3. Qt4 ist in dieser Hinsicht wesentlich flexibler geworden wobei es immer noch der Fall ist dass nur der Hauptthread zeichnen darf/kann. Allerdings haben in Qt4 mittlerweile auch alle QThreads eine eigene Message-Loop was ein Rendering im Hintergrund ohne weiteres möglich macht (siehe die examples). Das die Framereaten nicht so hoch sein können wie bei 'handgeschriebenen' Code erklärt sich von allein, aber ich denke wenn man sich etwas mit QThreads und der ganzen Kommunikation innerhalb einer Qt-Anwendung auseinandersetzt sollte der Unterschied nicht wirklich gross sein.