locked
Possible memory leak when using GraphicsWindow.Clear() method ? RRS feed

  • General discussion

  • I'd like to ask if anyone has noticed a memory bloat in your program when using GraphicsWindow.Clear() a lot of times for clearing your graphicswindow before a ui update. I calculated that for a graphics window the size of 500 * 500 each clear adds about 5 mb of memory to my program (noticed via task manager) - the amount of memory increased depends on the size of the graphicswindow. The program eventually shaves off the added memory but that doesn't happen until it is already bloated up to multiple hundreds of megabytes - then the process repeats since you keep using clear() to update your window, and if you clear your graphicswindow very few times it still bloats, just very slowly. I get around this by filling the entire window with a white rectangle instead of using the clear method, which is a shame because it makes it impossible to create transparent graphicswindows (using the ltdev library). Any ideas ?

    I am attaching my program where I noticed this happening - it is a show cursor x y position hud program :

    LDGraphicsWindow.Style = 0
    LDGraphicsWindow.TopMost = "true"
    
    GraphicsWindow.CanResize = "false"
    GraphicsWindow.Left = 0
    GraphicsWindow.Top = 0
    GraphicsWindow.Width = 150
    GraphicsWindow.Height = 20
    GraphicsWindow.BackgroundColor = GraphicsWindow.GetColorFromRGB(255, 255, 255)
    GraphicsWindow.BrushColor = GraphicsWindow.GetColorFromRGB( 0, 0, 0)
    GraphicsWindow.PenColor = GraphicsWindow.GetColorFromRGB( 0, 0, 0)
    GraphicsWindow.PenWidth = 3
    
    While ("true")
      mousex = Mouse.MouseX
      mousey = Mouse.MouseY
      mousepos = "x = "+mousex+"   y = "+mousey
      GraphicsWindow.Clear()
      GraphicsWindow.DrawText(0, 0, mousepos)
      Program.Delay(500)
    EndWhile


    • Edited by Lord_Archon Saturday, November 11, 2017 3:57 PM
    Saturday, November 11, 2017 3:54 PM

All replies

  • Hi,

    I can reproduce, but I cannot see anything in SB code that would cause native memory leaks.  All code here is managed and handled by GC (garbage collection).

    In fact if I pause your code after a while (actually using SB-IDE debug) and perhaps touch a couple other window the memory goes down to original levels showing that the GC has decided to clear resources.

    Tuesday, November 14, 2017 6:19 PM
  • Hi,

    I can reproduce, but I cannot see anything in SB code that would cause native memory leaks.  All code here is managed and handled by GC (garbage collection).

    In fact if I pause your code after a while (actually using SB-IDE debug) and perhaps touch a couple other window the memory goes down to original levels showing that the GC has decided to clear resources.

    I see ! Is there any way to control the garbage collection from within smallbasic or is this something that is completely handled by windows ? 
    Wednesday, November 15, 2017 3:11 PM
  • GC is pretty much a .Net thing.  It can be controlled programmatically, but would need code changes to Small Basic.

    Usually it is my experience to not tinker with it, unless there are 'real' native memory leaks or temp files left dangling etc and let the OS work it out - when resources get low it is more aggressive - micromanaging usually degrades performance.

    So my suggestion would be try to think of another way to manage the program without clear() if possible or alternatively, live with the large memory usage in the knowledge that the OS and GC are probably working to do what is needed to keep performance good even it looks like they are being wasteful.

    Wednesday, November 15, 2017 7:07 PM