›

Temps de latence lors de l'ouverture des préférences

muqaddarmuqaddar Administrateur
17:22 modifié dans API AppKit #1
Salut,

Lorsque que j'ouvre ma fenêtre des préférences, l'affichage est de plus en plus long, suivant que je l'ouvre une fois, deux... jusqu'à  x fois. Je parle ici de l'affichage de son contenu (des vues), et non de la fenêtre elle-même.

Voilà  mon code pour faire appel à  l'ouverture des préférences :

Dans mon mainController :

<br />- (IBAction)IBA_showPrefs:(id)sender<br />{<br />	//if (!prefsControleur) {<br />		prefsControleur = [[prefsController alloc] init];<br />//	}<br />	[prefsControleur showWindow:self];<br />}


Le prefsControlleur est releasé dans le dealloc. Le if est commenté parce que sinon la fenêtre ne s'affiche pas au deuxième appel. Il faudrait forcé le release ailleurs peut-être ?

Ensuite, dans ma classe prefsController, qui est une sous-classe de NSWindowController :

<br />- (id)init<br />{<br />	self = [super initWithWindowNibName:@&quot;Preferences&quot;];<br />	return self;<br />}<br /><br />- (void)windowDidLoad<br />{	<br />	//fenetre au premier plan<br />	[_IBO_wndPrefs makeKeyAndOrderFront: nil];<br /><br />	//instance barre outils<br />	[self setupPrefsToolbar];	<br />}<br />


J'ai aussi le delegate - (BOOL)windowShouldClose: (id)sender dans prefsController, qui pourrait éventuellement envoyer un message de release dans la classe mainController ?  :why?:

Réponses

  • ClicCoolClicCool Membre
    17:22 modifié #2
    dans 1122712938:

    Salut,
    .../...
    Le prefsControlleur est releasé dans le dealloc. Le if est commenté parce que sinon la fenêtre ne s'affiche pas au deuxième appel. Il faudrait forcé le release ailleurs peut-être ?


    Salut chef,

    Ton problème ne vient-il pas simplement de ce que tu ne gardes pas, dans une variable d'instance, la référence à  ton prefsControlleur ?

    A mon sens il faudrait laisser le if (et ne pas le releaser avant le déalloc "général") et voir pourquoi ça marche pas comme ça ...

    Parceque sinon désallouer pour recréer chaque fois ton controlleur c'est pas ce qui se fait de plus rapide comme procédure non ?
  • muqaddarmuqaddar Administrateur
    août 2005 modifié #3
    En fait, _prefsController est bien une var d'instance, je viens d'ajouter un underscore pour mieux le voir.

    <br />- (IBAction)IBA_showPrefs:(id)sender<br />{<br />	if (!_prefsControleur) {<br />		_prefsControleur = [[prefsController alloc] init];<br />	}<br />	[_prefsControleur showWindow:self];<br />}


    Pour ce qui est de l'allocation du controlleur de prefs, et bien j'ai fait comme ds le livre Cocoa par la pratique...
    Par contre, pour désallouer , je ne vois pas comment faire d'autre que de la forcer ?
  • ChachaChacha Membre
    17:22 modifié #4
    Une idée : l'utilitaire "leaks" de la ligne de commande, qui essaye de repérer des fuites mémoire.
    Lance ton appli, récupère son PID (avec un "top" ou le Moniteur d'activité)
    exécute leaks <le pid>
    ensuite ouvre tes préférences, et ré-exécute leaks
    ferme/réouvre les préférences et ré-exécute leaks
    S'il y a des grosses fuites mémoire, à  chaque exécution de leaks tu verras quels types d'objets sont en train de croupir dans la mémoire quand tu utilises les préférences.

    Sinon, nous as-tu donné tout le code contenu dans tes préférences ? As-tu essayé de désactiver tout sauf le strict nécessaire ?

    +
    Chacha
  • muqaddarmuqaddar Administrateur
    août 2005 modifié #5
    Salut Chacha,

    J'ai suivi ta procédure. Lorsque j'ouvre les prefs, il y a un leak en plus. Cependant, si je les ferme, et que je les réouvre, il n'y a pas encore un leak en plus...

    Je ne pense pas que le problème vienne d'une faille mémoire et de la classe prefsController, mais plutôt de son appel. Je vais re-regarder l'exemple dont je me suis servi.

    EDIT : Si je fais :
    - (IBAction)IBA_showPrefs:(id)sender<br />{<br />	if (!_prefsControleur) {<br />		NSLog (@&quot;toto&quot;);<br />		_prefsControleur = [[prefsController alloc] init];<br />	}<br />	[_prefsControleur showWindow:self];<br />}


    bien évidemment le "toto", n'est appelé que la première fois. On dirait que le showWindow n'est efficace qu'une fois. Car tout ce qui se passe dans la classe prefsController n'est appelé que la première fois également. Je précise que ma fenêtre est bien une fenêtre et non un panel.
  • Eddy58Eddy58 Membre
    17:22 modifié #6
    Il y a un exemple fort utile dans la doc developper, et il est très bien comme base d'appli multi-fenêtrée en plusieurs nibs : :)
    C'est dans : Developer/Examples/InterfaceBuilder/SimpleMultiWindow
  • muqaddarmuqaddar Administrateur
    17:22 modifié #7
    J'ai regardé cet exemple, et vérifié par rapport à  mon cas. Malheureusement, le problème persiste, même avec un code similaire dans mon application ! :(

    Je ne vois vraiment pas d'où peut venir le problème.
  • Eddy58Eddy58 Membre
    17:22 modifié #8
    Une grande partie du boulot se fait dans les fichiers nib, ils sont aussi similaires au point de vue du principe ? ???
  • muqaddarmuqaddar Administrateur
    17:22 modifié #9
    dans 1123019214:

    Une grande partie du boulot se fait dans les fichiers nib, ils sont aussi similaires au point de vue du principe ? ???


    Absolument. Ma deuxième fenêtre appartient au deuxième Nib, et le File's owner est bien personnalisé avec la classe prefsController.

    C'est fou que ça ne marche qu'une fois. Comme je le disais plus haut, le showWindow:self fait apparemment son boulot qu'une seule fois !
  • Eddy58Eddy58 Membre
    17:22 modifié #10
    Curieux, et dans IB l'option "Release when closed" de ta fenêtre n'est pas cochée ? ???
  • muqaddarmuqaddar Administrateur
    17:22 modifié #11
    dans 1123068924:

    Curieux, et dans IB l'option "Release when closed" de ta fenêtre n'est pas cochée ? ???


    Merci de me soutenir. ;-)
    Cochée ou décochée, ça ne change pas le problème. :(

    A quoi sert le window baking ?
  • Eddy58Eddy58 Membre
    17:22 modifié #12
    Le backing, c'est la façon dont est stockée ta fenêtre en mémoire : Buffered, retained ou non retained. Ce paramètre agit sur la façon dont se redessine la fenêtre, au niveau de la mémoire vidéo. Il est fortement recommandé d'utiliser le buffered backing store pour ne pas avoir d'ennuis de rafraichissement. :)
    Mais bon sinon, là  je vois pas ou se situe le problème, mais quelque chose me dit que c'est tout c.. .
  • muqaddarmuqaddar Administrateur
    17:22 modifié #13
    Et bien ça y est, j'ai trouvé mon erreur.

    Dans mon Nib, j'avais relier le file's owner à  l'outlet de ma fenêtre qui se nomme "_IBO_wndPrefs", mais PAS à  l'outlet "général" on va dire appellé window par défaut.

    Merci de ton aide Eddy, c'était bien une erreur de Nib.
  • Eddy58Eddy58 Membre
    17:22 modifié #14
    Ha tu vois bien que c'était tout c.. . ;)
Connectez-vous ou Inscrivez-vous pour répondre.