2009-10-08 3 views
7

Il ya quelque temps j'ai posté une question liée à une fuite de mémoire WriteableBitmap, et bien que j'ai reçu des conseils merveilleux liés au problème, je pense toujours qu'il y a un bug grave/(erreur faite par moi)/(Confusion)/(Une autre chose) ici.Comment disposer d'un bitmap inscriptible? (WPF)

Donc, voici à nouveau mon problème:

Supposons que nous ayons une application WPF avec une image et un bouton. La source de l'image est un bitmap très grand (3600 * 4800 px), quand il est montré au moment de l'exécution, l'applicaton consomme ~ 90 Mo.

Supposons maintenant que je souhaite instancier un WriteableBitmap à partir de la source de l'image (l'image vraiment grande), lorsque cela se produit, les applications consomment ~ 220 Mo.

Maintenant vient la partie délicate, quand les modifications de l'image (à travers la fin de WriteableBitmap), et toutes les références à WriteableBitmap (au moins ceux que je connais) sont détruites (à la fin d'une méthode ou en les mettant à null) la mémoire utilisée par writeableBitmap devrait être libérée et la consommation de l'application devrait revenir à ~ 90 Mo. Le problème est que parfois il revient, parfois non.

Voici un exemple de code:

// The Image's source whas set previous to this event 
private void buttonTest_Click(object sender, RoutedEventArgs e) 
    { 
     if (image.Source != null) 
     { 
      WriteableBitmap bitmap = new WriteableBitmap((BitmapSource)image.Source); 

      bitmap.Lock(); 

      bitmap.Unlock(); 

      //image.Source = null; 
      bitmap = null; 
     } 
    } 

Comme vous pouvez le voir la référence est locale et la mémoire doit être libéré à la fin de la méthode (ou lorsque le collecteur d'ordures décide de le faire). Cependant, l'application pourrait consommer ~ 224 Mo jusqu'à la fin de l'univers.

Toute aide serait géniale.

Répondre

0

Est-il nécessaire de rendre l'image bitmap avec la même résolution et les mêmes pixels? Vous pouvez créer l'writeablebitmap à un ensemble de pixels beaucoup plus bas et appeler la méthode de rendu. Puisque le writeablebitmap porte une référence aux uielements originaux lors de l'appel de render, dans ce cas, vous allez avoir 3 morceaux: 1) uielement original, 2) pixels dans writeablebitmap, 3) référence à l'original copié.

J'ai eu un problème similaire avec le WriteableBitmap en termes de fuites de mémoire et je l'ai fixé de vérifier ce lien: http://www.wintellect.com/CS/blogs/jprosise/archive/2009/12/17/silverlight-s-big-image-problem-and-what-you-can-do-about-it.aspx

Si vous créez un autre WriteableBitmap et de copier les pixels sur, puis jetez la première WriteableBitmap vous devriez voir une libération de mémoire - au moins, je l'ai fait dans mon scénario.

Questions connexes