g.dropShadowFromPath got funky on macOS between May 30 and July 02

[aaronventure]

There was a whole month of broken macOS commits, and the first one that compiled is cac7a45f4cd70a2f0ad96771ea8df1c10bfd2de7 from July 02.

However this broke dropShadowFromPath for my PaintRoutined custom keyboard and I can't figure out why. It also looks like this on the latest commit.

Like the path is a tiny dot or something.

The last one that has it working correctly is the last working macOS commit before that, on May 30.
a20873ea7a8c00b251ddae7df8d6e3007f8c5f71

This is what it should look like

@Christoph-Hart Any idea what could've broken it?

[ustk]

@aaronventure Yeah noticed the same, I needed to replace the area that was taking the object bounds with the path bounds in the whole project:

When was the Rectangle API introduced? Might come from this...

[d.healey]

@aaronventure That's a damn fine keyboard.

[aaronventure]

@ustk said in g.dropShadowFromPath got funky on macOS between May 30 and July 02:

@aaronventure Yeah noticed the same, I needed to replace the area that was taking the object bounds with the path bounds in the whole project:

When was the Rectangle API introduced? Might come from this...

I can't make any sense of this, I didn't use getLocalBounds, I use calculated dimensions based on keyboard parameters... How are you getting the correct positions for the shadow?

@d-healey Thanks! It's even got conditional shadows!

It's also fully configurable!

This was my "alright, let's get a full hang of this Paint Routine stuff" moment when I was learning HISE. I think it took me a better part of a week.

With a bit softer shadows

[Chazrox]

@aaronventure NICE!

[ustk]

@aaronventure said in g.dropShadowFromPath got funky on macOS between May 30 and July 02:

I can't make any sense of this, I didn't use getLocalBounds, I use calculated dimensions based on keyboard parameters... How are you getting the correct positions for the shadow?

Since the path is made at the right dimension, its bounds are just the area I need.
Effectively it doesn't make any sense because in the end the area is the same as the previous one. I think the issue comes from a conversion behind the scene, but why...

[Christoph Hart]

Yeah it might be caused by the change to melatonin shadow rendering I did around that time.

I might have introduced a silly mistake though:

If you change this line:

HISE/hi_scripting/scripting/api/ScriptDrawActions.cpp at cdb23d4c24e93ef487127f125742a6443d4e76a2 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_scripting/scripting/api/ScriptDrawActions.cpp at cdb23d4c24e93ef487127f125742a6443d4e76a2 · christophhart/HISE

GitHub (github.com)

to

p.scaleToFit(a.getX(), a.getY(), a.getWidth(), a.getHeight(), false);

Does that fix the problem?

[ustk]

@Christoph-Hart said in g.dropShadowFromPath got funky on macOS between May 30 and July 02:

p.scaleToFit(a.getX(), a.getY(), a.getWidth(), a.getHeight(), false);

Confirmed, that's the one

[aaronventure]

@Christoph-Hart That it, thanks.