[FR] GlowEffect::applyEffect() with position

General JUCE discussion
1

Any chance of changing/adding GlowEffect::applyEffect() to:

void GlowEffect::applyEffect (Image& image, Graphics& g, float scaleFactor, float alpha, int x /* = 0 */, int y /* = 0 */)
{
    Image temp (image.getFormat(), image.getWidth(), image.getHeight(), true);

    ImageConvolutionKernel blurKernel (roundToInt (radius * scaleFactor * 2.0f));

    blurKernel.createGaussianBlur (radius);
    blurKernel.rescaleAllValues (radius);

    blurKernel.applyToImage (temp, image, image.getBounds());

    g.setColour (colour.withMultipliedAlpha (alpha));
    g.drawImageAt (temp, x, y, true);

    g.setOpacity (alpha);
    g.drawImageAt (image, x, y, false);
}

Thanks,

Rail

2

Well, applyEffect is an overloaded method so doesn’t that throw a warning/error?

3

Yes, it did (I only implemented it after my post)… so I simply added an additional overloaded version of GlowEffect::applyEffect() to the class… but I could see that this should likely be changed in ImageEffectFilter and all the derived classes.

BTW -That’s why I edited the word “changing” in my original post to “changing/adding” :slight_smile:

Cheers,

Rail

4

Gotcha. Will be on develop shortly.

1 Like
5

Thanks Jules.

100% off topic… I notice you set default values in the header and removed them from the init list. Is this going to now be the recommended JUCE coding style? Do we know if this has any difference in the way the compiler creates the code? I’m imaging none and this is for readability… but thought I’d ask :wink:

Off to Google!

EDIT: Okay - This covers it pretty well…

So I can see the advantage with multiple constructors, but also the down-side where aggregate initialization is desired.

Thanks!

Rail

6

…and this leads to the next C++11 coding style question…

Would you prefer

glow.setGlowProperties (1.0f, Colours::grey, Point<int>(0, 7));

vs

glow.setGlowProperties (1.0f, Colours::grey, {0, 7});

I lean towards the latter – but I’d like to keep my code adherent to the JUCE coding style.

Cheers,

Rail

7

Yeah, we’ve been tending to prefer member initialisers now, it just makes the code a bit shorter and can prevent a few typos. Haven’t come across any places yet where it caused problems with aggregate initialisation.

And yes, I’d probably go for the { 0, 7 } too.