QTreeView performance
Meine klasse CTreeModel ist von QAbstractItemModel abgeleitet und schliesst eine lücke zwischen QAbstractListModel und QStandardItemModel. Das erstere kann nur einfache listen, beim zweiten muss man eine hierarchische liste in einen item-baum übertragen (also etwa ein logbuch mit unterzeilen je tag). Und da hat initiator OregonGhost völlig recht, die performance dabei ist echt 'grottig'. Mein model implementiert die hierarchischen teile einfach mit verschachtelten vektoren (das ergibt n-dimensionaltiät) und kann jede QModelIndex-basierte anfrage des view in O(1) beantworten. Zusammen mit einem QTreewView funktioniert das ganze eigentlich auch hervorragend. Nur als ich alle items expandiert haben wollte, brach der QTreeView zusammen. Ich habe die ursache dafür gefunden ... und der vorschlag am besten einen eigenen CTreeView zu bauen ist durchaus richtig aber nur zeitlich etwas abwegig. Entscheidend ist, dass es eine gute lösung geben könnte, die massiven performance probleme aber von TT hausgemacht sind. Das ist echt schade und deshalb ärgert es mich so.
Wir schreiben hier auch Programme, die nen Busverkehr ueberwachen ...
Und wir bekommen bis zu 14k telegramme pro sekunde
und ja, wir stellen es in nem treeview dar.
Wie einer schon hier im thread schrieb, 14k / s irgendwas darzustellen ist bloed. sieht ja sowieso keiner ....
WIchtig ist, das man die eingangsevents vom paint trennt.
Also man 14000 mal was in ein "model" reinschreiben kann, sich aber das treeview trotzdem nur aller 0,5 s (bei uns einstellbar) updatet ....
Alles andere laeuft auf internen datanstrukturen ab.
Das dein treeview "flackert" wiesst definitiv drauf hin, das deine input events direkt auf das treeview malen .... selbst mit der winapi oder mfc, die das vielleicht performancetechnisch hinbekommen, wenn der user ne weile draufschaut, wuerde er wahnsinnig werden ^^
Ciao ...
Und wir bekommen bis zu 14k telegramme pro sekunde
und ja, wir stellen es in nem treeview dar.
Wie einer schon hier im thread schrieb, 14k / s irgendwas darzustellen ist bloed. sieht ja sowieso keiner ....
WIchtig ist, das man die eingangsevents vom paint trennt.
Also man 14000 mal was in ein "model" reinschreiben kann, sich aber das treeview trotzdem nur aller 0,5 s (bei uns einstellbar) updatet ....
Alles andere laeuft auf internen datanstrukturen ab.
Das dein treeview "flackert" wiesst definitiv drauf hin, das deine input events direkt auf das treeview malen .... selbst mit der winapi oder mfc, die das vielleicht performancetechnisch hinbekommen, wenn der user ne weile draufschaut, wuerde er wahnsinnig werden ^^
Ciao ...