Feature request: paint (g) wrapper macro


#1

I wrote a class that is a timer for paint (Graphics& g) calls. And then I have a window that pops up and shows how much time each class is spending in it’s paint routine. I find it much easier than using a profiler to see what is affecting paint performance, mainly because I always have it open, so I immediately see if I change I made affected performance.

The downside is I need to hack it into juce every time there is a juce update. It would be nice if there was a macro kinda like JUCE_ENABLE_REPAINT_DEBUGGING, that let me wrap paint calls. maybe JUCE_ENABLE_PAINT_WRAPPING.

If it’s enabled, then the app has to provide two functions paintStarting (Component* c) and paintEnding (Component* c)

I know it’s a pretty niche request, but it would be nice.


#2

Maybe you should consider having your Juce in a git repo? I’ve myself made some changes into the Juce source code and I can pull Juce updates using git…There are sometimes merge conflicts but those don’t happen that often.


#3

If anybody else wants this, here is the code. Just add #define JUCE_ENABLE_REPAINT_TIMING to your AppConfig.h and then call showTimingWindow (true); somewhere after JUCE has started up, and then you get this:


#4

Replace your component files with these (rename from .txt)

juce_Component.h.txt (109.5 KB)
juce_Component.cpp.txt (101.8 KB)


#5

…why can’t you just inherit from Component and then use it as base class for these components you want to profile? I think all you need is virtual…
This would have much less impact in the existing code, even none if you want to profile your own paint calls.
If you want to profile e.g. slider, you could just alter that header file to inherit your profiling component instead of the original component.


#6

Mainly I want to see everything, I don’t always have a good idea what is slow. On a plugin I am working on now, turns out drawing the background of my main plugin window was the slowest thing. I never would have suspected that.