Site navigation

SVG Development?

General JUCE discussion
#1

We are currently testing the SVG support in JUCE and it seems to be lacking quite a lot of things (fonts, filters, etc).

Basically anything our graphic designers export are visible in most programs we try except for when we use the JUCE SVG-Parser, unless they are very simple (straight up geometry with color works obviously)

Are there any plans to implement more functionality from SVG?

If not and we decide to start developing this ourselves, do you have any tips on where to start? We prefer not to "hack" the JUCE code at all and just rely on our own external files.

#2

Filters aren't done yet, but we do have basic font support.

If you have specific files that almost work but not quite, please let us know, as it might be an easy fix!

#3

No not really, I have some files that arent working at all more or less :P But that is due to filters being used in excess on those ones.

Do you know when or "if" you will start implementing filter support? 

We are kinda running out of options if we want to create nice looking GUIs that are scalable without doing a SVG-parser ourselves.

#4

Would like to support full SVG but haven't resources to do that in the near future. Small fixes would be possible.

It's surprising that you're having so many problems though, as I know many people (including us) are using SVG and rarely hitting any files that don't work. Can't your editor software flatten things like filters?

#5

Im not a graphic artist and really have very little experience handling SVG files in general so im not sure what "flatten" means in this discussion.

Im assuming it is some kind of conversion from a "filter: blur..." style component in the SVG file to standard geometry + color information? The only "flatten" we found in illustrator was "flatten transparency" which I assume is not what is what you mean by "flatten".

Our graphics people use illustrator and affinity designer when drawing SVGs, they didnt know what "flatten" meant either since they normally just draw things as they want and it works :)

#6

Sorry, I don't use these apps either and don't know the right term, but yes, I did mean that it should be possible for them to simplify things like text and effects down to basic geometry and gradients.

#7

I tried to use Illustrator to create SVG files as well, but I had trouble using them in Juce and the SVG files created by Illustrator were huge.  So, even if they were rendered in Juce correctly, I'm not sure if I would have wanted to use them.  So, I personally walked away from that experience blaming Adobe for doing a crappy implementation of SVG.  Other people on this forum have mentioned using Inkscape instead to create SVG files. 

#8

Not sure how you would expect SVG to be able to "flatten?" Unless JUCE's SVG implementation supported the image element... (http://www.w3.org/TR/SVG/struct.html#ImageElement)

#9

The image element doesnt seem to cut it anyways since thats basically just a standard pixelbased image which by definition is not scalable.

Feels weird to have a file format called "SCALABLE vector graphics" and have features that makes it non-scalable :)

#10

There are utilities to reduce the size of SVG's -

e.g. https://www.npmjs.com/package/svgo

and as a web app: https://jakearchibald.github.io/svgomg/

#11

Quite aware of all that! But afaict, it's the only feasible way to bake in effects but still use an SVG. :)

#12

I revive this old post now since we are back from vacation and have started catching up on the SVG part of things.

We managed to solve our issues with the SVG not being visible at least (basically by simplifying everything), BUT, I see some performance issues when rendering these files.

Basically I made a simple implementation of a rotary slider (knob) using SVGs (through custom look and feel as advised).

The SVG itself is quite small and simple (about 8kb file size).

I then added about 240 of these knobs horizontally inside a viewport with a horizontal scrollbar, I then animated the sizes of the knobs from their original size to about 10x so that I go from having 20 visible knobs to about 2 and this made the performance drop like crazy. I have a timer doing the repaint at 60hz and with 20 knobs visible i have a steady 60fps but when scaling them up to the point of having only 1 or 2 visible, the fps drops to around 35-40fps.

I dont know if im using it wrong, something in the JUCE renderer is wrong, or if this is just how it is?

Running the JUCE demo project with the SVG render demo shows similar effects when scaling up so I dont think im using it wrong (or the demo does it wrong as well :) )

 

Any ideas?

 

Edit: I just noticed that this happens even with the default look and feel's rotary slider!

#13

Well, drawing big paths is a very CPU-intensive task! Try the GL rendering engine if you're not already doing so.

And whenever you hit performance issues, the first thing you do should always use a profiler before reporting things as being "wrong". It'll always give you more insight into what's happening, and often shows up some surprises.

#14

Well, drawing big paths is a very CPU-intensive task! Try the GL rendering engine if you're not already doing so.

Thanks for the reply, it seems to be very CPU-intensive indeed! Running in release build, 1 SVG scaled very high caused the framerate to drop below 10 on my computer. (Pretty decent computer even). Unfortunately I cannot use the GL renderer which would a good boost without a doubt.

And whenever you hit performance issues, the first thing you do should always use a profiler before reporting things as being "wrong". It'll always give you more insight into what's happening, and often shows up some surprises.

Yeah thats true, it was a very very simple scenario I was testing however so I didnt see a reason to profile it to see if I did something weird that was causing performance issues. 

 

Are there any people who used SVG extensively on 4k monitors for example where we would need to scale things up for visibility and still managed to maintain good performance? 

#15

On 4k monitor I definitly advise to use GL renderer.

We have a preference which allowsthe user to enable/disable it in our future product.

#16

FYI we're planning to add new rendering engines for Vulkan + Apple Metal which use the GPU to rasterise paths, so this stuff should be very very fast in the future. The existing CoreGraphics + software renderers are CPU-bound (but still about as fast as a CPU renderer can be). The current GL renderer is faster, but still not as good as we'll be able to do with the next gen of GPU APIs.

What happened to the Direct2D Renderer?
#17

Great to hear you're planning to support Vulkan and Metal! Thanks for letting us know.

Vulkan looks promising
https://www.youtube.com/watch?v=P_I8an8jXuM
https://www.khronos.org/vulkan