to use the new dsp module, I updated my current project to 5.1 today. But after the first build I was a bit shocked, as my GUI looked completely unusable.
At the moment the GUI is still under development and I use a rough sketch for building the more important algorithm parts in the background. Now, until yesterday it looked like this:
It is completely made up of SVG images, with one big static image in the background helping me positioning the elements (that’s why some knobs & buttons can be seen twice). As I said, it’s a sketch, it’s a bit ugly, but all in all it looks as expected.
Now after the JUCE 5.1 update it suddenly looks like that:
Check out this this level meter for an example. You can see it in the upper screenshot with the text beneath it, while in the lower screenshot the text is gone and therefore the graphic is stretched.
Another example is the background image containing some text and filling the whole viewport in the upper screenshot while being much to small & lacking all text in the lower one. You’ll find it here.
The images are stored as binary data and then drawables get created from them. These are all painted with the help of Drawable::drawWithin
Since iterating using a range-based for loop and the new Component::getChildren() method this always iterates forward through the child components. This might have unintended side effects where some of these changes (specifically in the drawables stuff) were for iterating the child components in reverse?
Well, I’m not so deep into the JUCE codebase that I had an idea why this change could affect svg rendering this way… However I temporarily got it working (or should i say drawing? ) again by just exchanging the whole juce_gui_basics/drawables folder with a 5.0.x version of that folder. That way it works, but I’d prefer to work on a clean clone of the current JUCE git.
Thank you @martinrobinson-2 for testing my image in your app, this is exactly what it used to look like and how it should look like.
That’s OK! I was checking as some of the recent changes were some that I sent to Jules. Plus we’re making heavy use of the SVG stuff here so wanted to check if this breaks what we’re doing.
I double-checked the changes to the SVG class but can’t see any problems. Can’t help feeling this might be something else you’re doing in your code that’s messing it up. Perhaps you’re changing a transform somewhere?
If you use Projucer to load the level meter graphic that you linked, it does look correct (although very small)
Yes, that was my mistake in the code I sent you I think. Use <use> tag applied to shapes was already working but not for images and other types of element.
So when it hit this:
if (xml->hasTagName ("use"))
return useShape (xml, path);
It was returning and not resolving URLs to things like gradients in the element. It should just pass through the rest of parseShape()
Unfortunately, I haven’t had (and still don’t have) the time to take a deeper look into this problem.
I checked out the last commit on develop which obviously applied a patch to the svg parser, but my problem is still there. I hope I’ll find some time for some testings next week to find out under what circumstances the drawing fails.
Just to be sure, could you post the lines of code you used to successfully draw my level meter?
It doesn’t look correct, all text is missing in this graphic as well as in every other svg file for my GUI. This text was definitively shown before 5.1.
Second, RectanglePlacement::stretchToFit doesn’t work as it worked before with these images, that’s the reason why they are so small. It seems to only fill 25% of the width and height of the rectangle passed in
Drawable::drawWithin
The only thing I do is creating a rectangle to paint the image in and then draw it, just like this:
) again by just exchanging the whole juce_gui_basics/drawables folder with a 5.0.x version of that folder. That way it works, but I’d prefer to work on a clean clone of the current JUCE git.
