Die Threadpriorität hat natürlich keine Auswirkungen auf deinen Anwendungsfall, denn Du gibst (ohne das sleep) dem
OS überhaupt keine Gelegenheit, andere zum Zuge kommen zu lassen. Threads sind kooperativ, d.h. sie müssen 'Bescheid' geben, wann und wo sie unterbrochen werden können. Offensichtlich trifft das auch auf den Prozess zu, obwohl ich dachte, das Windows hier präemptives Multitasking umsetzt.
Aber offensichtlich ist es so: Du und deine Freunde teilen sich eine Pizza. Du hast großen Hunger, also gibst Du dir eine hohe Priorität. Das funktioniert dann, wenn jeder sich reihum einen Haps nimmt (alle einen gleich großen), nur Du darfst jeweils einen großen Bissen nehmen. Logisch: Wenn sich alle eine hohe Priorität geben, ist der Effekt auch = 0. Und bahnbrechend ist der Effekt eh nicht, nur du bekommst eben ein wenig mehr (weil deine Freunde mitspielen und wenig abbeißen).
Wenn Du allerdings die Pizza nicht mehr aus der Hand gibst, ist es irrelevant, ob Du eine hohe oder sehr niedrige Priorität hast, weil ja dann das verabredete Prozedere (jeder reihum abbeißen) nicht eingehalten wird. Du ißt sie also ganz alleine auf. Entweder mit kleinen Bissen (niedrige Priorität) oder mit Riesenhapsen (hohe Priorität).
Da wir nicht wissen, was Großartiges mit dem 'Graphics g' anstellst, kann man da auch nicht weiter ansetzen.
Ach: Wieso ist das eigentlich ein 'high CPU mistake'? Wenn schon ein 'mistake', dann eher von Dir bzw. dem Design.
Der Thread rennt endlos ohne Pause und rendert irgend etwas? Was rendert er? Wann ändert sich etwas bei der Darstellung? Reicht es nicht, das Rendern nur dann anzuwerfen, wenn es etwas *Neues* zu rendern gibt, d.h. wenn sich der Output ändern wird? Reicht es nicht, nur z.B. 20x pro Sekunde zu Rendern?
Zitat
Baum-Darstellung
