[New Module] Melatonin Blur

[bwall]

I don’t know if this applies in your case, but I have seen odd artifacts present themselves occasionally when using setOpaque(true).

[sudara]

@Stevezee Can you pull the latest from GitHub? I think your problem should be fixed.

@bwall

I have seen odd artifacts present themselves occasionally when using setOpaque

I’m crossing fingers and assuming you mean JUCE generally and not this module! But if not, please let me know

[bwall]

Yes, it was JUCE generally.

[Stevezee]

Yes, I’ve yet to install IPP but I’m looking into that right now.

[sudara]

Hmm, I doubled down in the end, spent a few more weeks and just pushed a huge update. To everyone who tried it out so far: thanks for the fixes and feedback. Please update and let me know how it’s feeling.

In addition to fixes, improved API and tons more correctness tests, there’s a slew of new features like “retina” blur/shadows by default, additional caching, setters for each shadow parameter, support for stroked path drop/inner shadows, and a new demo component.

Most of us using Stack Blur have been (unknowingly?) rendering low quality shadows (vs. at graphics context scale). Rendering at the correct scale makes a big difference in percieved quality. Scaled up lower density shadows look boxy/grainy vs. luxurious:

Another biggie: I added another layer of caching at the single channel level. This means you can now translate the source path, change shadow color, offset and opacity — all for “free” (the shadow is reused, you only pay for compositing).

That makes for very cheap 60fps animation of those attributes:

This very short…er…low quality gif of the demo component shows sub-millisecond rendering of 4 retina shadows with 15px blurs… in Debug (on my macOS M1).

Ok, going to take that break from open source now. Really really really. But do let me know how it’s going if you are using it!

[sudara]

Just merged one last feature before the new year:

That image above is made with this code:

class TextShadowDemo : public juce::Component
{
public:
    void paint (juce::Graphics& g) override
    {
        // https://codepen.io/namho/pen/jEaXra
        juce::String text = "TEXTSHADOW";
        g.fillAll (juce::Colour::fromRGB (236, 229, 218));
        g.setFont (font.withExtraKerningFactor(-0.1f));

        // drop shadow renders under the text!
        dropShadow.render (g, text, getLocalBounds(), juce::Justification::centred);
        g.setColour (juce::Colour::fromRGB (241, 235, 229));
        g.drawText (text, getLocalBounds(), juce::Justification::centred);
    }

private:
    juce::Font font { "Arial Black", 110.f, 0 };
    melatonin::DropShadow dropShadow {
        { juce::Colour::fromRGB (196, 181, 157), 12, { 0, 13 } },
        { juce::Colours::white, 1, { 0, -2 } }
    };
};

It uses the same DropShadow and InnerShadow classes and mimics the g.drawText API for now, more info here.

[PeterRoos]

Impressive, thanks man
I can ditch some of my own cumbercome code for this effect now

[matt]

That’s nice!

[reFX]

[stephenk]

Been following awhile. Need to try this out, it seems awesome.

[sudara]

It’s open source and the priority so far has been compatibility, tests, and performance. There’s an open issue for warnings, you are welcome to contribute (or wait until it’s resolved).

Compiler warnings

[sudara]

All is fine, I opened that issue a month ago exactly because I figured somebody would complain

@PeterRoos

a let’s-fix-it-in-the-mix situation (by others??)

You didn’t mean it this way, but I actually consider this to be a great description of open source’s best feature!

Whether it be docs, tests, warnings, compatibility, performance, code quality, feature completion, bugs, build systems — if a someone cares enough about their issue, they have the opportunity to directly address it and improve the software they are using.

most issues should not have been written in the first place

To be fair, the first iterations of the module probably were warning-perfect (yes, I use linting :)) However, I wrote a couple dozen implementations, many went through several iterations, as did all the caching and glue code. After the second or third iteration, I stopped wasting time on constantly juggling things like getting std’s size_t and JUCE’s int relationship pixel-perfect until I knew I had an implementation that was actually going to survive. Not sure what to do with the 10 or so “extra” implementations (unused except for tests) but they can also be fixed up or removed so they don’t anger people

reliability and robustness

For me, the 2500 lines of tests passing on multiple platforms are my measure of reliability and robustness. Eventually, I’ll flip the switch so that a compiler warnings will fail tests (like my other projects). Pleasing various compilers is a typically a last-ish step for me on a project, not a first step. Not quite there yet (but would welcome a PR!).

[reFX]

Why are you so rude about it? You make it sound as if this code you paid for and Sudara owes you something.

I’m also a stickler for warning free code, but you really have to be more diplomatic about stuff like this.

Don’t be discouraged @sudara

Merry Christmas

[PeterRoos]

To Sudara and Michael:

I am sorry for venting irrelevant opinions in my posts, I have deleted them.

I should have only mentioned this observation:

when I included the module in a released project, the number of compiler warnings went up from 13 to 4950.

Have good and relaxed days

[eyalamir]

Tip for both module devs and module users:

You can add a couple of files that suppresses warnings.
Here’s how it works:

//WarningsStart.h

#pragma once

#include <juce_core/system/juce_TargetPlatform.h>
#include <juce_core/system/juce_CompilerWarnings.h>

#if JUCE_MSVC
JUCE_BEGIN_IGNORE_WARNINGS_MSVC(4267 4127 4244)
#else
JUCE_BEGIN_IGNORE_WARNINGS_GCC_LIKE("-Wconversion",
                                    "-Wdeprecated-register")
#endif

//WarningsEnd.h:

#pragma once

#include <juce_core/system/juce_TargetPlatform.h>
#include <juce_core/system/juce_CompilerWarnings.h>

#if JUCE_MSVC
JUCE_END_IGNORE_WARNINGS_MSVC
#else
JUCE_END_IGNORE_WARNINGS_GCC_LIKE
#endif

Then in your module header/cpp, or on your user code that uses the module you can do:

#include "WarningsStart.h"
//Include module code that may generate warnings
#include "WarningsEnd.h"

[sudara]

@PeterRoos

number of compiler warnings went up from 13 to 4950.

Something is definitely off! There should only be a small handful of actual warnings remaining in the main module.

The module should include max 1500-2000 LOC, so 5k warnings would be… a Christmas (anti) miracle. It sounds like maybe you are manually adding all files in the repo, including those belonging to the Tests and Benchmarks target (both use Catch2 Generators, and happens to be the main place I was lazy about unsigned vs. signed). Those files should only be included when you are writing tests/benchmarks on the blur module itself. If that’s not the problem, please open an issue and let me know how you included the module.

[eyalamir]

@sudara

Something is definitely off! There should only be a small handful of actual warnings remaining in the main module.

I think if someone uses your module, and includes your_module.h (or JuceHeader.h, which includes it) in a lot of compilation units, the number of warnings would multiply dramatically.

[PeterRoos]

I will send you information, pre/post config, output samples, etc.

If your instructions for adding the git submodule and how to include your Juce module via the Projucer were not correct, please let me know.

[kunitoki]

Is there a way to remove the dependency on juce_audio_basics ? Seems rather an unnecessary dependency (maybe the juce team should consider moving the simd classes into a juce_simd module).

I also continue to get these warnings, didn’t you address them some months ago ?

[eyalamir]

@kunitoki

Seems rather an unnecessary dependency (maybe the juce team should consider moving the simd classes into a juce_simd module).

I strongly support this message (making FloatVectorOperations and related functions a separate module).

Would you mind suggesting that here (and voting, if you didn’t already)?

FR: more compact JUCE module headers

We have quite a lot (30+) custom JUCE modules used in multiple products, unit tests, etc, and I noticed that adding any JUCE module include to a module can really inflate compile times, compared to the same module without any JUCE includes. It would be great if some of these high level modules could be split into more compact modules. For example: I’m fine with juce_gui_basics bringing in a bunch of widgets, and no backwards compatibility should be broken for that module. But - in modules wit…