FS#4730 - OutOfMemory im Softdeskt wegen nicht vorhandenem MVVM durch verwendung der SerializableBitmap
Project laden,
SoftDesk Öffnen
MacroBoardProfil öffnen
Converter-Effecct auf die Matrix in der StatgeView legen und warten bis es knallt
OutOfMemory.dmz
(18,7 KB)
Da war noch nen bug in dem Bitmap from Matrix node, der das beschleunigt hat.
Für den test die Height und Width in dem Node mal auf 4000 setzen
Ist der OOM im Kernel oder GUI bei dir? Ich hab im Matrix to Bitmap Node mal H/W auf 2048 gesetzt und das ganze laufen lassen (im Debug Modus, durch VS gestartet) Sowohl Kernel als auch GUI sehen gut aus. Speicherverbrauch bleibt stabil. Das Bild ruckelt zwar im Softdesk aber das liegt daran, dass der Node 0,5 Sekunden braucht.
EDIT: Ah. There I see
Nachfrage: Was macht dich so sicher, dass es am MVVM liegt, also das Peer das Binding nicht verwendet? Der Code des BitmapToImage Converters ist ja der gleiche, beides mal in WPFTools.
EDIT: Ok, ich sehe schon. Im Macro Board gehts, und da wird das Binding verwendet.
Hier wäre aber die Frage, wenn man das Softdesk sowieso umbaut, sodass es im Kernel lebt, dann kann man denke ich auch MVVM in die Controls einführen. Macht dann denke ich Sinn.
Das der selbe Code aus den WPF-Tools genommen wird hab ich schon geändert gehabt.
Das Problem daran, das die ImageSource nicht per Binding gesetzt wird, ist, das Die ImageSource immer sofort(erzwungen) gesetzt wird. In MVVM wird die erst gesetzt, wenn WPF meint, das es das Bild jetzt brauch, oder luft hat.
Bevor ich da noch den Bug im BitmapFromMatrix gefixt hab hab ich halt immer ein 4000x4000 bitmap generiert und ins softdesk gepumpt, da kamm der GC nicht mehr hinterher
Das MacroBoard ist noch WinForms
Aber hier Dispose ich alle alten Bitmaps, wen eine neue kommt.
Im WPF werden alle Bilder gehalten, egal, ob sie noch verwendet werden oder nicht, erst wenn der GC um die Ecke kommt wenn der Speicher knapp wird räumt der die weg.
mmn. war das auch UnmanagedMemory
Ok, aber wenn man Bilder in normalen Größen (~128x128) generiert, dann tritt der Fehler nicht so schnell auf. Ich denke das ist OK, das so zu lassen bis das Softdesk in 3.4 auf Kernel umgebaut wird. Dann muss man da eh ran, und kann auch MVVM durchziehen.