Repaint redraw bounds

General JUCE discussion
1

I can’t quite figure out how juce is figuring out what portions of the screen are “dirty” and need to be repainted.

Specifically, when switching between tabs on a tabbed component, I sometimes find that my application repaints the appropriate boxes of one tab even when that tab is no longer the one selected. The image below is an example of this … the inset shows the previously selected tab. I assume that juce figured out what areas to paint, but somehow didn’t remember to recalculate when I switched tabs (there is probably a changemessage in there somewhere that is not getting serviced?).

The same occurs for comboboxes … I have a fileBrowserSelector, but after changing the directory it takes several seconds to refresh the treeview.

I am assuming these are efficiency issues on my part … but I believe I am doing everything in the most efficient manner (the audio processor generally takes <3% cpu). Further, it seems like the message manager should be higher priority than paint … and that change messages should be serviced before redrawing the ui … but maybe this is not the case for reasons that I don’t see.

Anyway, I am hoping for general advice on the most efficient way to repaint large applications. None of my larger components have timers to call the repaint method (they seem to be smart enough to know to repaint often). Is it better to have the smaller components that should repaint often have their own timers, or just item->repaint() from the parent windows paint methods? Is there a way to tell the UI to recalculate what areas to repaint when the tabs are switched? Is there a way to see what percentage of cpu cycles are taken up by the paint() method? Is this worthwhile?

Finally, what I’m afraid is at the root of it …
If repaint() is called before paint finishes … will the program check for change messages and recalculate the areas to be repainted before running repaint again or not?

One other question … I have never done any openGL programming and I am wondering if the lower level graphics rendering methods used by JUCE are openGL calls, or if I should perhaps consider making some of the larger image objects (the one that displays the incoming waveform for example) into openGL objects, and then learning how to draw them with GL commands. I this faster/better/ the standard way to do that … or is it reasonable to expect that I can draw a large image 20-30 times a second with juce methods?

2

Calling repaint inside your paint method is a bad design and best avoided. But it is possible, and what should happen is that the areas will be flagged as dirty after the paint method returns, and be repainted next time around. In the latest tip code I think that all works, but if you’re using an older version, it might not do it correctly. Much better to NOT do any repainting in the paint method though!

There’s currently no opengl used in rendering. On the mac it uses CoreGraphics, and this will all get faster as I change more of the graphics code to use native rendering methods. I’d say try getting it working the straightforward way, and see what happens before worrying about optimising. It should be possible to render some pretty large areas at that refresh rate.

3

excellent - thanks for the pointers, Jules!