Code: Alles auswählen
void setImage(QImage *image)
{
QMutexLocker locker(&m_Mutex);
if(m_Image)
{
delete m_Image;
m_Image = NULL;
}
m_Image = image;
update();
}
Das Update da drinne, was macht das genau ?
Schiesst das auf irgend eine GUI funktion (Paint event) ? dann musst du eh entkoppeln und hasst keine andere Wahl. Denn wir wissen, GUI funktionen innerhalb der qt duerfen nur vom Main thread aus aufgerufen werden.
Deswegen machts auch keinen Sinn, im paintevent was locken zu wollen ^^ Das muss einfach probleme geben.
Mit Signal/Slots kann ich leider nicht arbeiten, da es leider nicht mein Thread ist, und ich aus nem fremden Thread keine signals senden kann.
klar , das ist doch auch deine crux, das dich der andere thread aufruft, oder ? das heisst du kannst in dem aufruf "einfach" einen threadwechsel herbeifuehren .... das kannst ueber signale und slots, aber auch ueber events oder ganz selbst machen.
um signale von dem nichtmainthread abzuschicken, brauchst du nicht mal eine eventqueue, die in dem nichtmainthread laeuft ! nur wenn signale empfangen willst, brauchst die ....
Einzig und allein der gueltigkeitsbereich von deinem pointer auf die daten wird ein problem, weil ueber threadgrenzen hinweg die signale assynchron arbeiten, du also im nichmainthred ned weisst, wann dein pointer vom mainthread abgearbeitet wird und dementsprechend wann ihn loeschen kannst und wann ned.
EIgentlich macht man sogar auch in nicht qt programmierung in solchen faellen oft expliziete kopien, einfach um sich verwaltungsoverhaed zu sparen. Die frage ist, wie gross das Image ist, um abzuschatzen was performanter ist.
Zur Zeit benutz ich wieder die Pointer, die will auch mein Chef haben, da zu viel kopieren das System träge werden lässt.
QImage ist eh nen pointer auf daten, das heisst intern ist das ding nen zeiger mit lazy copy funktionalitaet.
Auf grund der generizitaet und der threadsicherheit wird aber nen QIMage seine daten kopieren, wenn den ueber ne assynchrone Signal/Slot verbindung schickst.
Von woher bekommst du eigentlich die Daten fuer das bild ? Aus nem Stream ? ich wuerd wahrscheinlich das handling der Daten im multithreading context abhandeln, und das ganze GUI zuegs, also daten zu bild, und bild anzeigen im mainthread abhandeln, und schoen entkoppelt von dem dateneingang, so das man vielleicht sogar statt 60 auf 30 fps oder weniger runner takten kann ....
wie solarix scho sagt, das scale kann uebel aufewendig sein, warum das oefters machen als notwendig ^^
übrigens, wenn man perofrmant sein will, sollt man sich ueberlegen ob man zigmal ein new xyz aufruft, QImage in diesem Fall. unnoetiges und haeufiges new / malloc is ne riesen-perofrmancebremse.
Statt dem new QImage sollt man sich ueberlegen, nicht besser das alte QImage ned weiterzuverwenden und an dem einfach das load / loadFromData aufzurufen !
Ciao ...
