virtual memory rising on "repaint()" call

16 posts / 0 new
Last post
leskimo
Offline
Last seen: 8 years 5 months ago
Joined: 25 Jan 2006 - 15:18
virtual memory rising on "repaint()" call

Hi,

In my previous post I asked if it was possible to make some vertical progressbar, to make a VU Meter. Then Rock Hardbuns gave me a code to display a VU Meter. Here is this code:

#ifndef _METERCOMPONENT_H_ 




class MeterComponent   :   public Component, public ChangeBroadcaster { 
private: 
GradientBrush* brsGreen; 
float value; 

public: 

   MeterComponent() : Component( T("Slider Field Component") ){ 
        value = .5f; 
        brsGreen =  new GradientBrush(Colour(0,200,0),0,0,Colour(200,200,0),0,100,false); 

   } 


   ~MeterComponentComponent(){ 
       delete brsGreen; 
      deleteAllChildren (); 
   } 


    void paint (Graphics& g){ 
        //background 
        g.setColour(Colour(0,0,0)); 
        g.fillRect(0,0,getWidth(),getHeight()); 


        g.setBrush(brsGreen); 
        g.fillRect(0,int(getHeight() * (1-value)),getWidth(),getHeight()); 

        //bevel outline for the entire draw area 
        g.drawBevel(0, 0, getWidth(), getHeight(), 2, Colour(100,100,100), Colours::white, 0); 
    } 

    float getValue(){ 
        return value; 
    } 

    void setValue(float v){ 
        value = jmin(jmax(v , .0f) , 1.0f);
        repaint();  // this is the line I added
    } 

};

As I wanted the VU Meter to repaint itself when I set a value, I added a call to "repaint()" after setting the value in "setValue(float v)". But I just remarked that this call to "repaint()" make the virtual memory rise a lot. In fact it doesn't stop rising till I stop my process.. Could it be linked with this call, or should I search somewhere else? Thanks in advance for your help.

I've created a thread to update my VU Meter. I set the value from the "run()" method. Maybe it has a link with my problem..

Leskimo

gravity always wins

jules
Offline
Last seen: 6 hours 18 min ago
Joined: 29 Apr 2013 - 18:37

Well painting does allocate off-screen bitmaps that will take up quite a bit of memory. It's probably just that. If you're leaking, then you'll get warned about it when the app quits (if you're using VC++).

Rock Hardbuns
Offline
Last seen: 3 years 1 month ago
Joined: 22 Nov 2005 - 00:10

Hey!

I never actually tested that code. I just ripped it from another component I made which is sort of an array of sliders I used for making wavetables.

Though, I can't see what could be wrong with it.

I guess you could try replacing the gradient with a solid colour. Or call repaint for the parent component...just to see if the behaviour is still there.

edit > doh, Jules slipped in ahead of me. :?

leskimo
Offline
Last seen: 8 years 5 months ago
Joined: 25 Jan 2006 - 15:18

Well I tried to call the parent component's repaint method, or to change the gradient for a solid color, but the problem is still here.. It is really annoying because it doesn't stop rising, so at a certain point (when there is no virtual memory left..) it makes the application crash. How did you do to refresh your meters if you didn't call the "repaint()" method?

gravity always wins

jules
Offline
Last seen: 6 hours 18 min ago
Joined: 29 Apr 2013 - 18:37

erm.. no, I just meant that it would allocate a chunk of memory, not leak to the point of crashing!

Memory leaks are easy to debug:

- quit the app
- look at the list of leaked objects
- figure out what they are (easy if you've used the juce_UseDebuggingNew macro)
- look at where they're allocated

jules
Offline
Last seen: 6 hours 18 min ago
Joined: 29 Apr 2013 - 18:37

BTW calling repaint() from a thread is dangerous unless you use a MessageManagerLock - doesn't it throw an assertion?

Rock Hardbuns
Offline
Last seen: 3 years 1 month ago
Joined: 22 Nov 2005 - 00:10

leskimo wrote:
How did you do to refresh your meters if you didn't call the "repaint()" method?

Well, since it was a input component originally, it repainted after certain mouseMove calls, I.E changes to the sliders settings.

leskimo
Offline
Last seen: 8 years 5 months ago
Joined: 25 Jan 2006 - 15:18

nope, calling repaint() from a thread doesn't throw me any assertion. But the problem is the same if I use for example a messageListener to update my VU Meters each time my class receive the corresponding message.
About the memory leaks: the compiler doesn't tell me that there is any leak, it just seems to be perfectly normal..

gravity always wins

Rock Hardbuns
Offline
Last seen: 3 years 1 month ago
Joined: 22 Nov 2005 - 00:10

For what it's worth, I just did a very simple test with a meter component controlled by a plain slider, and I can't seem to get anything to happen as far as memory goes, no matter how much I yank that slider up and down.

jules
Offline
Last seen: 6 hours 18 min ago
Joined: 29 Apr 2013 - 18:37

Are you sure you're building it in debug mode? In a release build you'd get no assertions or leak info..

leskimo
Offline
Last seen: 8 years 5 months ago
Joined: 25 Jan 2006 - 15:18

you're right, I was in release mode.. I searched but didn't find any explanation on how to use the juce_UseDebuggingNew macro. Could you explain me how I can figure out what the leaked objects are?

gravity always wins

Pages