Release memory consumed by redraw

[SaschArt]

I find a problem: when the graphic redraw (called by SetDirty(), IsDirty() and Redraw()) the plugin take a few megabytes from memory and never release them. If the user change too much knobs will consume lot of memory, this is real problem.

Also graphics with dynamic components need continuous redraw which take a lot of memory.

How to release memory after redraw ?

[Xenakios]

Do you have some custom control class you've written that leaks memory when it draws itself?

There's not much more advice to give than to recommend not using raw pointers and manual new/delete. Prefer value based objects first but if not possible, then use smart pointers.

[Xenakios]

Originally Posted by SaschArt

If the user change too much knobs will consume lot of memory, this is real problem.

This may also be because of the host application storing undo states. Is your plugin's state data very large?

[SaschArt]

Sure have custom control build by me to draw graph with bool IsDirty() { return true;}

Problem is to intersect checking.

Return intersect and redraw even if not really intersect.

[Xenakios]

Originally Posted by SaschArt

Sure have custom control build by me to draw graph with bool IsDirty() { return true;}

Problem is to intersect checking.

Return intersect and redraw even if not really intersect.

What does this have to do with memory use? Why is your custom control using and apparently leaking memory when it draws itself?

[SaschArt]

Using CropBitmap() again and again. Can I cache cropped bitmap in the next call load from cache ?

[SaschArt]

Any solution to cache cropped bitmap in a custom control to prevent using CropBitmap() to each refresh ?

[SaschArt]

I find a solution to store CropBitmap() result in cache and problem solved. I define cacheBitmap type of IBitmap var in IControl then use this code in my custom control

if (cacheBitmap.W==0)
  cacheBitmap=pGraphics->CropBitmap(....

simple and working

[Xenakios]

Originally Posted by SaschArt

I find a solution to store CropBitmap() result in cache and problem solved. I define cacheBitmap type of IBitmap var in IControl then use this code in my custom control

if (cacheBitmap.W==0)
  cacheBitmap=pGraphics->CropBitmap(....

simple and working

CropBitmap seems to be adding the cropped bitmap into a cache of its own by calling RetainBitmap...That seems to be working weird, I suspect there's actually a memory leak/overuse going on there.

The cropped bitmaps are added to the IGraphics internal bitmap cache with an ID of -1 and there appears to be no check if a bitmap with that ID is already there. Effectively, it appears calling CropBitmap just keeps on adding bitmaps into the IGraphics cache, with no way to control it. Maybe someone who knows IPlug/IGraphics better can say if I've understood the code correctly? (I don't have an IPlug project at hand here, so I just have to imagine how the code works by reading it.)

[Tale]

Yeah... I guess copped bitmaps should get a unique ID, just like normal bitmaps, so they can be cached properly between instances. It should probably assert that the dimensions of the cropped bitmap match that of the bitmap in the cache.

[FelixMagi]

CropBitmap has another problem, it's a dynamically member assigned there: LICE_MemBitmap* pDest = new LICE_MemBitmap(destW, destH); and never deleted

[Tale]

I think pDest is added to the static (global) bitmap cache using RetainBitmap(), and so it's deleted by ~BitmapStorage().

[SaschArt]

The problem with CropBitmap is that it does not allocate the unique ID, allocates -1 to all, must be assigned an unique ID and then loaded after the ID. Also the ID must be saved in the IBitmap structure. That's how it loads:

IBitmap IGraphics::LoadCropBmp(int ID) {
  LICE_IBitmap* lb = s_bitmapCache.Find(ID);
  return IBitmap(lb, lb->getWidth(), lb->getHeight());
}

The same problem is with ScaleBitmap()