Erzeugen der Objekte im Thread geht nicht?
Ich ken mich da leider zu wenig mit Python und dem zeichnen ausum dir dabei genau helfn zu können-aber vom Prinzip her hast du es (wenn ich diese spez. Dinge weglasse schon gut gemacht da du es auslagerst.)
BTW:
Wie oft musst du zeichnen?
Mainthread sinnvoll ausnutzen
Ja, nur hilft dir das ned weiter ^^Nein, warum denn? Ich kann schon damit leben, dass das Bild eventuell auch mal verzögert dargestellt wird, wenn man denn seine Eigenschaften (mit Slidern oder mit dem Mauscursor) zu schnell ändert.
Stell dir vor, Du schaffst es, deine mouseevents zu entkoppeln, die Aenderung in nem anderen thread vorzunehmen . dann hasst 2 szenen, und musst die in dem View austauschen, mit QGraphic* hasst keine chance das zu entkoppeln, ergo deine GUI "Steht" immer 12 sek.
Vorrausgesetzt es betrifft immer alle elemente.
trifft es paar wenige, kannst du die betreffenden elemente(QGraphicsItems) direkt aendern, bestimmst die region die es betrifft, laesst die region neu zeichnen. Wie lange das dauert, haengt natuerlich von der komplexitaet ab, und wenns mehrere regionen betrifft, kannst die nacheinander neu zeichnen lassen, nachdem der gui mal wieder bissi luft zum reagieren gegeben hasst. Aber im schlimmsten fall wird die GUI trotzdem paar sek stocken. Mit QGraphics* hasst keine andere Chance, sorry.
Na dann grats zur A-Karte ^^Ich habe gar kein Win. Ich habe Linux. Und es soll natürlich auch auf dem Mac laufen. Ja, und auch unter Windows.
Was du braeuchtes, iss ne lib die multithreaded auf einem "Fenster" "Malen" kann .... und plattformuebergreifend(winapi + X) zur verfuegung steht.Hab ich leider keine erfahrungen mit. Aber vielleicht kann dir jemand anders helfen.
Prinzipiell koennen beide Fenstersysteme, also winapi + X , multithreaded bemalt werden. Am meisten nutzen Spiele sowas aus, da iss performance eh nen Thema, vielleicht suchst mal in der richtung.
SDL hab ich gehoert gibts fuer beide Systeme, keine ahnung ob die sowas kann ... und vor allem ob die sich "nur" aufn Fenster haengen kann, damit DU in deinem Rahmen ausenrum weiterhin python und qt verwenden kannst.
Noch ne andere Idee waere vielleicht:
Die beschraenkung der QT betrifft die threads .... Zumindest in der winapi kann man aber auch innerhalb einer Fensterhirarchie mit unterschiedlichen prozessen arbeiten. Unter X muesste das auch gehen, aber bin ned sicher. Aber eigentlich grade da sollt es gehen.
Also Fuer dein View der RahmenApp nen leeres fenster zeichnen lassen. Nen neuen Prozess erzeugen, der sich das fensterhandle schnappt (keine Ahnung ob das mit qt unter X geht, unter windows geht es definitiv). Die prozesse muesstest ueber ne Pipe
PC) kommunizieren lassen, also da auch die ganzen events (resize, mouse events) etc rueberschicken. beide Prozesse koennten QT verwenden. Aber du haettest Nebenlaeufigkeit und QT !!! Ob es wirklich geht, haengt auch mit ab wie sich die preozesse gegenseitig auf einem Handle (Windows oder X) mit den Events in die quere kommen.
Alternativ kannst das natuerlich auch entkoppeln, in dem fuer jeden prozess nen eigenes Hauptfenster machst, und damit die Controlls und der view in unterschidlichen toplevel windows liegen, also eher so nen aufbau wie bei gimp oder dem designer im Single windows modus.
Ob es das Wert iss, nur um dafuer bei der QT zu bleiben ??? Ich fuer mich wuerd definitiv "Nein" schreien und wie wahnsinnig weglaufen ^^
Ciao ...