Drawable's copy constructor / createCopy() doesn't copy clip path

Drawable now has a drawableClipPath member now, but it isn’t copied in the copy constructor. Something like this is missing in Drawable::Drawable (const Drawable& other):

if (other.drawableClipPath != nullptr)
    setClipPath (other.drawableClipPath->createCopy());

Also, someone shoot me please :frowning:
This took me forever to find.
After reporting OpenGL issues (that were already fixed in our fixes branch) and having them fixed correctly (which reduces my git merge burden), I could try to evaluate JUCE 5 again, merging it into our JUCE fixes branch.
I then noticed that SVGs stopped looking right in one of our plugins.
They didn’t look right in Projucer too so I figured which of my SVG fixes I didn’t merge properly with ROLI’s changes. But then even though I did get it to look right in the Projucer it still didn’t look right in our plugin.
Like I often do when lost, I tried git bisecting, but it doesn’t work well with branches (btw anyone have tips for that?), so I ended up bisecting only on commits from ROLI’s repo where at each step I merge with our branch and test that. That was tedious because there were a lot of merges to do where our code deviated with fixes mostly for OpenGL and SVG stuff. At last I found that things stopped working when JUCE added support for clip-paths in SVGs.
I compared Jules’s clip-path patch to mine and couldn’t really find what’s wrong with Jules’s, it seemed perfectly fine. I tested and reviewed and re-reviewed Jules’s patch and at the end I figured that this member copy was missing.
And what made me look into JUCE 5 again in the first place? Trying to use/test its the oversampling, which btw I now tend to believe is faulty too but I don’t have the time to thoroughly test it at the moment.

Cheers, Yair

3 Likes

Damn, thanks for finding that! Will get it updated asap!

1 Like