›

NSThread et mono-processeurs

muqaddarmuqaddar Administrateur
05:09 modifié dans API AppKit #1
Salut,

NSThread permet de "séparer des calculs ou méthodes" dans des threads différents.
J'ai lu que c'était surtout pratique et efficace pour les multi-processeurs.

Est-ce que ça peut aussi être utile sur les mono-processeur ou est-ce simplement une "feinte" pour les mono-processeur ?

Dans mon cas, j'aimerai séparer l'affichage texte et image sur 2 threads différents, ça fera aussi effet sur les mono-processeurs ?

Réponses

  • fouffouf Membre
    05:09 modifié #2
    Ce n'est pas une feinte : ca te permet de reactualiser ton affichage sans ralentir ton soft. Apres, tout depend du type d'affichage.
    Dois-tu faire une boucle qui reactualise l'affichage (animation) ?
  • muqaddarmuqaddar Administrateur
    05:09 modifié #3
    Oui.

    Un thread avec méthode qui gère le texte à  afficher (avec des sleep).
    Un thread pour l'animation.

    Et le thread principal...

    J'ai fait un test, ça semble marcher pour le texte, les sleep n'entrainent pas le ralentissement du soft. Mais je suis sur un double CPU, donc ma question était : "ça sera preil sur un mono -CPU ?" :)
  • SystemSystem
    05:09 modifié #4
    ça marchera, mais moins bien que sur un bipro. Installe les CHUD Tools (fournis avec les devtools) et débranche le second processeur, comme ça tu peux voir par toi même.
  • muqaddarmuqaddar Administrateur
    05:09 modifié #5
    OK, merci.

    Tient j'ai regardé Thread viewer.
    C'est génial comme soft ! Je vois bien mes 3 threads avec leur autorelease. :)
  • maconnectmaconnect Membre
    05:09 modifié #6
    salut,
    attention: tout ce qui est affichage doit être fait sur le main thread!! Donc à  chaque fois que tu appelles "display", "setStringValue",... et tout ça ça doit être sur le thread principal. Sinon, ça plante aléatoirement (par exemple quand la fenêtre concernée est réduite). L'affichage n'est PAS thread safe.

    Il faut donc faire:
    [self performSelectorOnMainThread:@selector(setStringValue:) withObject:@salut waitUntilDone:NO];

    Par exemple
  • muqaddarmuqaddar Administrateur
    05:09 modifié #7
    Merci.

    Oui, le pb doit venir de cela. mpergand m'a expliqué cela par mail...

    ++
  • muqaddarmuqaddar Administrateur
    mars 2005 modifié #8
    dans 1111223606:

    salut,
    attention: tout ce qui est affichage doit être fait sur le main thread!! Donc à  chaque fois que tu appelles "display", "setStringValue",... et tout ça ça doit être sur le thread principal. Sinon, ça plante aléatoirement (par exemple quand la fenêtre concernée est réduite). L'affichage n'est PAS thread safe.

    Il faut donc faire:
    [self performSelectorOnMainThread:@selector(setStringValue:) withObject:@salut waitUntilDone:NO];

    Par exemple


    J'ai essayé cette technique mais mon texte se monte toujours dessus au bout d'un moment, même en renvoyant l'affichage ds le main thread...
    :(

    Je suis sur une autre piste, je vous tiens au courant.
    ++
  • muqaddarmuqaddar Administrateur
    05:09 modifié #9
    Voilà , vu que je suis dans une vue, j'ai fait cela, mais je ne sais pas si c'est recommandé :

    [self performSelectorOnMainThread:@selector(setNeedsDisplay:) withObject:@YES waitUntilDone:NO];

    et dans drawRect :

    - (void)drawRect:(NSRect)rect {
    [sendText drawAtPoint:NSMakePoint(0, 0) withAttributes:stringAttributes];
    }

    En tout cas, ça marche !!!
    Le texte ne se monte plus dessus.  :kicking:
  • cbrandtcbrandt Membre
    05:09 modifié #10
    oui mais non:

    setNeedsDisplay veut un booléean (BOOL) en paramètre, pas un objet !

    un booléen est juste une valeur numérique... 0 pour NO et diff. de 0 pour YES...

    donc quand tu passes @YES, tu lui passes l'adresse d'un objet (la chaà®ne de caractères), qui est différente de 0, et donc il considère que c'est un YES booléen (coup de bol)...  tu aurais passé @NO, ou @TOTO ça aurait été pareil...
  • muqaddarmuqaddar Administrateur
    mars 2005 modifié #11
    Et donc je dois mettre quoi ds l'objet ?  :)beta:
  • ClicCoolClicCool Membre
    05:09 modifié #12
    [NSNumber numberWithBool:YES] :)
  • muqaddarmuqaddar Administrateur
    05:09 modifié #13
    Ah, merci. Je suis bêta. ;)
  • cbrandtcbrandt Membre
    05:09 modifié #14
    dans 1111358167:

    [NSNumber numberWithBool:YES] :)

    pas d'accord... setNeedsDisplay attend un booléen, pas un objet...
    si c'était une méthode perso, dans ce cas ok...
  • ClicCoolClicCool Membre
    05:09 modifié #15
    dans 1111395686:

    dans 1111358167:

    [NSNumber numberWithBool:YES] :)

    pas d'accord... setNeedsDisplay attend un booléen, pas un objet...
    si c'était une méthode perso, dans ce cas ok...


    Oups tout à  fait j'en étais resté à  ton post précédent sans le remettre dans le contexte de setNeedsDisplay  >:)
  • muqaddarmuqaddar Administrateur
    05:09 modifié #16
    Je vous suis pas... je mets quoi alors ?
  • cbrandtcbrandt Membre
    05:09 modifié #17 
    <br />[self performSelectorOnMainThread:@selector(setNeedsDisplay:) withObject:@&quot;YES&quot; waitUntilDone:NO];<br />

    ça marche pour YES, mais c'est par hasard...
    si tu veux que ce soit propre, fais comme ça:
    <br />[self performSelectorOnMainThread: @selector (mySetNeedsDisplay:) withObject: [NSNumber numberWithBool: YES] waitUntilDone: NO];<br />...<br />- (void) mySetNeedsDisplay: (NSNumber*) yesNo<br />{<br />    [self setNeedsDisplay: [yesNo boolValue]];<br />}<br />
  • muqaddarmuqaddar Administrateur
    05:09 modifié #18
    Merci cbrandt. Mieux vaut faire propre en effet.
  • maconnectmaconnect Membre
    05:09 modifié #19
    non pas besoin de faire tout ça.
    Tu mets
    [truc setNeedsDisplay:YES];
    Et c'est tout. Pas besoin de le faire sur le main thread, ça sert a rien du tout. Cette fonction ne sert PAS à  redessiner l'objet, ça indique simplement qu'il devra être redessiner lors de la prochaine loop
Connectez-vous ou Inscrivez-vous pour répondre.