Wozu hat QWidget Double-buffering?

AlgorithMan · Beitrag von **AlgorithMan** » 21. April 2010 12:41

Ich habe gelesen, dass QWidget Double-buffering benutzt, aber dafür scheint es keinen vernünftigen Grund zu geben, denn man kann in QWidgets doch nur in der paintEvent Methode reinzeichnen. Während dieser Methode sollte aber der zweite Puffer gesperrt sein, weswegen es keinen unterschied zum einfachen buffering gibt...

Ich meine double buffering ist doch dazu da, dass der bildschirminhalt korrekt bleibt (weil aus dem zweiten buffer gelesen wird) auch wenn man während dem Expose Event noch zeichnet (eben im ersten buffer). Die Beschränkung auf paintEvent bewirkt aber doch, dass man überhaupt nicht in den ersten buffer zeichnen KANN während der zweite auf den bildschirm übertragen wird, weil man nur zeichnen darf unmittelbar bevor der erste buffer in den zweiten übertragen wird, wobei der zweite gesperrt ist und daher währenddessen nicht auf den bildschirm übertragen werden kann

ist die Beschränkung auf paintEvent ein Relikt aus zeiten vor double buffering? Die beschränkung gehört imo abgeschafft...

RHBaum · Beitrag von **RHBaum** » 21. April 2010 13:59

Neee ....

Ich meine double buffering ist doch dazu da, dass der bildschirminhalt korrekt bleibt

Nein, Double Buffering iss dazu da das dein bild ned flackert eigentlich ...
http://de.wikipedia.org/wiki/Doppelpufferung
Das ist der Hardwarebuffer.

Im SW Bereich hasst das selbe nochmal, beispiel windows:
Du malst auf ein GDI ....
das malen selber ist schlecht zu serialisieren, bzw laeuft ziemlich langsam. Deswegen wird der GDI ned direkt an die graka geschickt, sondern erst auf nen 2ten GDI mittels bitblt(recht schnell) kopiert und der erst zur Graka geschickt.

Effekt: deine Paintroutine kann unbekuemmert auf dem GDI rummalen, erst wenn der volle paintvorgang abgeschlossen ist, wird der GDI rueberkopiert.
Das heist die Graka bekommt keine zwischenstaende vom paintvorgang, egal wie lange der dauert und wie oft du den aufrufst (schlimmstenfallls ist die software nur noch mit malen beschaeftigt.

Das heisst Deine Controls, bilder etc bauen sich ned so control fuer control am bildschirm auf wie bei urzeitlicher software manchmal zu sehen war, oder gar flackern weil man das "malen" zu schnell sieht, sondern sind schlagartig da, auch wenn das aufbauen relativ lange dauert ....

Ciao ....

AlgorithMan · Beitrag von **AlgorithMan** » 21. April 2010 23:40

Das kommt doch aufs gleiche raus... mit nur einem buffer muss entweder der bildschirm warten (dann flackerts) oder er stellt das unfertige, inkorrekte bild dar...

jedenfalls wird der ganze sinn davon ad absurdum geführt, wenn man nur dann in den ersten puffer schreiben kann, wenn man problemlos auch in den zweiten schreiben könnte...

was mich einfach tierisch nervt ist, dass man nicht einfach von ausserhalb auf widgets zeichnen kann und wenn ich das richtig sehe, kann man auch von innerhalb der widget-derivate nicht vernünftig darauf zeichnen (schon allein dass man QWidget ableiten muss, was im designer gar nicht geht, ist eine Zumutung!) - statt dessen muss man irgendwelche botschaften an die überschriebene paintEvent methode hinterlassen und repaint aufrufen... wie unnötig kompliziert geht's denn noch? man vergleiche das mal mit der TPaintBox in der VCL...

das ist ernsthaft eine der dümmsten interface-designs die ich je im leben gesehen habe - insbesondere weil es dank double-buffering keinen vernünftigen grund gibt, QPainter zu blockieren wenn es sich ausserhalb des paintEvent derivats befindet... Man könnte ja auf die pixmap malen (ich schätze mal das ist der erste buffer) WENN die verdammte methode keinen CONST pointer zurück liefern würde...

Ich habe mit sehr positiver erwartungshaltung angefangen, mich mit Qt zu beschäftigen, aber so ein hirnrissiges interface-design lässt mich echt die wände hoch gehen!

Es kann doch nicht wahr sein, dass ich als Diplominformatiker binnen 2 Tagen nichtmal nen verdammten Pixel auf die Form kriege (zumindest nicht ohne massive performance verluste durch die graphicsview)! So viel Zeit habe ich ja bald schon gebraucht um eine komplette Klasse zur verwaltung von XWindows auf API Ebene zu schreiben (inklusive double buffering, main-loop in einem eigenen thread, synchronisation der threads, event handlern, etc)...

Beitrag von **Christian81** » 22. April 2010 06:31

Wenn Du nur rumnölen willst - bitte woanders...
RHBaum hat alles ordentlich erklärt - Du möchtest es einfach nicht kapieren.

franzf · Beitrag von **franzf** » 22. April 2010 07:56

AlgorithMan hat geschrieben:Es kann doch nicht wahr sein, dass ich als Diplominformatiker binnen 2 Tagen nichtmal nen verdammten Pixel auf die Form kriege (zumindest nicht ohne massive performance verluste durch die graphicsview)! So viel Zeit habe ich ja bald schon gebraucht um eine komplette Klasse zur verwaltung von XWindows auf API Ebene zu schreiben (inklusive double buffering, main-loop in einem eigenen thread, synchronisation der threads, event handlern, etc)...

Irgendwie nehm ich dir das nicht ab...
Es gibt genügend Menschen, die innerhalb 2 Tagen ihre ersten kleinen Qt-Anwendungen geschrieben haben - keine Informatiker. Selbst mein kleiner 15-jähriger Bruder hat die Sache (mit meiner Unterstützung) recht schnell gerafft. Also mach mal Halblang. Die Doku ist klasse, hättest du nicht sofort versucht, alles selber zu machen oder dich auf den "doofen Double-Buffering" zu beschränken, wärst du jetzt vllt. weiter.

BTW.: Dass man nicht von außen einfach so auf ein X-Beliebiges QWidget zeichnen kann hat einen einfachen Grund, und der liegt nicht bei idiotischen Entscheidern, sondern bei OOP-Grundlagen: Kapselung. Von außen auf ein Widget zeichnen kommt einer public-Exponierung von Membern gleich, denn das Aussehen ist ja eben gerade die zentrale Eigenschaft eines Widgets! Wenn du mal selber ein komplexeres Widget entworfen hast, möchtest du ja auch nicht, dass jeder darauf rumkritzelt, vor allem wenn du dann mit events arbeitest und z.B. bei mouseMove Sachen veränderst - du bist froh, dass du die Bug-Reports nicht bekommst!
Und wenn du außerhalb eines paintEvent zeichnen willst, dann verwende ein QLabel und mal in deinen Methoden auf ein QPixmap und setze das dann.
Und warum hast du denn eigentlich ein QGraphicsView genommen? das ist ja noch mal ne Stufe weiter als ein QWidget, auf das malt man nicht so wie gewohnt, da malt man mit QGraphicsItems!

kater · Beitrag von **kater** » 22. April 2010 08:44

Code: Alles auswählen

    QImage image(100,100,QImage::Format_RGB32);
    image.setPixel(1,1, qRgb(100,100,100));
    QLabel label;
    label.setPixmap(QPixmap::fromImage(image));

Hier ein Beispiel, aber nur, weil ich genau das selbe Problem hatte als ich zum ersten mal Qt sah. Und vorher noch nie OOP mit so einem großen Framework gemacht habe.

(Vor meinem Studium hat man mir wohl zu recht empfholen nicht Informatik zu studieren, da man dort nicht Programmieren lernt

)

AlgorithMan · Beitrag von **AlgorithMan** » 22. April 2010 08:54

Die Lösung mit QImage kostet vermutlich auch zu viel performance... ich sag ja mit graphicsview hab ich's am laufen, aber die performance ist lausig! Ohne Übertreibung hatte ich damals in Turbo Pascal eine DEUTLICH bessere performance auf nem 286er auf dem Framebuffer!

kater · Beitrag von **kater** » 22. April 2010 09:10

Jup. Stimmt 100%. Willkommen in der Welt der langsamen, aufgeplähten, dicken fetten Frameworks die alles können, aber extremst lahm sind.
Wenn du damit nicht zurecht kommst, darfst du es nicht nutzen. Versteh dich vollkommen. Für Dinge die schnell sein müssen gibts immernoch pures hartes C gehacke mit inline assembler

franzf · Beitrag von **franzf** » 22. April 2010 09:35

Kannst du mal erklären, was du genau machen willst? QGraphicsView hat einen gewissen Overhead, dafür gehen manche Sachen richtig einfach!

Herzogswalder · Beitrag von **Herzogswalder** » 22. April 2010 11:54

Lieber AlgorithMan,

Der Vergleich mit Turbo Pascal hinkt - da sind einfach verschiedene Welten zwischen. Vielleicht solltest du dir einen moderneren Computer zulegen, dann klappt's auch mit dem Zeichnen.

Ich selbst bin von Turbo Pascal über Delphi und C# bei C++/Qt gelandet und geblieben. Es ist meiner Meinung nach das Beste Framework, welches für mehrere Plattformen verfügbar ist.

Außerdem habe ich den Eindruck, das du dir das nur mit einem Auge angesehen hast, vielleicht nur um zu meckern, anstatt sich, wie es jeder vernünfitge Programmierer tut, sich damit intensiv zu beschäftigen.

Deshalb lege ich dir ans Herz: wenn du wirklich ernsthaft mit dem Qt-Framework arbeiten willst, lies die Dokumentation!
Diese ist meiner Ansicht nach die beste Doku zu einem solchen Framework, die mir bis jetzt unter gekommen ist.

Wenn du dann noch Fragen hast, kannst du sie gern hier stellen, aber denke bitte daran, das der Ton die Musik macht.

In diesem Sinne - happy programming!