SVG rendering errors after updating to JUCE 5.1


#1

Hi,

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:

What has happened there? I notice that all text embedded in the SVG images is completely missing, and that things are scaled completely different now.

I couldn’t find any mention to changes in the SVG functionality in the release notes of 5.1…


Unable to render attached svg file
#2

Looks like a similar issue to the one I posted yesterday


#3

Can you send me an example of an SVG file that used to work but is now failing?


#4

Yes, it’s all open source :wink:

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


#5

Any news regarding this topic, @jules?
Or anyone else out here who experienced a similar issue after the update and maybe found a solution?


#6

Could it be this:

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?


#7

I’m still broadly on Juce 4 for our products except for the SVG changes (in juce_gui_basics/drawables) up to commit prior to the one linked above.

@JanosJuce : My SVG test app renders your image like this


#8

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? :smiley: ) 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 for testing my image in your app, this is exactly what it used to look like and how it should look like.


#9

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.


#10

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)


#11

Bumping this, because SVG rendering is broken (or at least previous files no longer work) on 5.1

Here’s some screen shots:

Compiled with 5.0.2:

Compiled with 5.1.1:

Here is a link to the SVG files.


#12

Problem appears to stem from to be this commit. Reverting before it solves my issues, how about yours?


#13

These specific changes were the culprit:
svg-fix.diff.txt (2.3 KB)


#14

Sorry, Martin, are you suggesting that removing that UseShape stuff would be a fix? I’m confused about what the actual problem is?


#15

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()


#16

Gotcha. Thanks, will apply that patch today!


#17

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?


#18

I didn’t write any code, I just dropped the file into the projucer to see if it would load it correctly.


#19

Thanks for the quick fix!


#20

Okay, I had the time to do a few test.

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:

Rectangle<float> backgroundArea (0, 0, getWidth(), getHeight());
backgroundImage.drawWithitn (g, backgroundArea, RectanglePlacement::stretchToFit, 1.0);

Any idea what could go wrong?