JUCE SVG and UI issues

[VincyZed]

• Here's 1.9 on the left, and XT on the right:

• Left - 1.9, right - XT. Slider groove is darker/more opaque and there's no semitransparent triangle.
  

• Unsure why the modbutton arrow is a different color here. Makes no sense, SVG shows brown and yellow states over here. Red is nowhere to be found?

• Different colored MSEG nodes and FX jog:

• From issue ED's XT pedantikons #4377: These things are back at 175% zoom (non-HiDPI):

• Issue with hoverOn00166.svg in Classic and Dark skins:

Chromium and Figma render it fine. Seems to be caused by the stroke in the last <path>:

[baconpaul]

Since I asked:

So on XT the colors are flatter (and darker)
It's the blue-gray ish gradient (lighter in the middle than on the sides) that we added in 1.8 iirc. This doesn't show up in XT, where it's all the same dark color everywhere, basically the "old 1.7" dark skin.
You can especially see it if you compare the FM routing and filter config area.

[mkruselj]

Hmmm SVG parser in JUCE not working with our specific type of gradient (or the way it's outlined in the SVG)?

EDIT: Possibly related - https://forum.juce.com/t/how-radial-gradients-are-defined-in-juce/11055

[mkruselj]

@baconpaul Please investigate why we cannot nicely center text vertically AND horizontally in the tempo block (VKB area), despite justification set to centred.

[baconpaul]

I remember now
If your text editor is small or your font is high the indents "win"
here's the line from TypeinParamEditor I used to fix this

  textEd->setIndents(4, (textEd->getHeight() - textEd->getTextHeight()) / 2);

[baconpaul]

which you should call in ::resized

[mkruselj]

OK fixed that, but now the colors aren't being shown correctly when starting up Surge, they only sort themselves out when typing in something and pressing Enter.

[baconpaul]

The dar skin radial gradient thing is actually an XT bug

Making the SVG more pronounced in that gradient here/s XT vs 19

and here's XT vs Boxy (chromium)

So the fix for dark skin fade is to adjust the SVG to work with a spec compliant renderer!

[baconpaul]

basically change this line

gradientTransform="translate(451) rotate(90) scale(451 451)"

in the SVG from 131.45 to 270.5 and you will get something closer to what 19 did

Seems 1.9 was not dealing with non-uniform scales on gradient transforms properly.

[mkruselj]

Aaaaand that's fixed. JUCE is still not rendering the raster texture that's part of that gradient but I guess that's up to them to implement?

Which then only leaves the Royal Surge issues.

[baconpaul]

The reason for the different colors in royal surge are because royal surge has odd svg. It might be standards OK but juce doesn't like it.

<path
     d="m 7.0500183,26.500023 -2.5,-3 h 5 z"
     id="path7164"
     fill="#f92a69"
     fill-rule="evenodd"
     stroke="none"
     style="fill:#f6d537;fill-opacity:1" />

here's the SVG for a chunk of the LFO arrow.

That's saying the fill is #f92a69 which is this color. This is the color juce renders.

But it is also saying there's a style with a fill. That fill is #f6d537

which is the desired color, and also the color chromium selects.

So the answer on these odd royal skin colors is: Royal gives two conflicting colors for the fill in their svgs. Chromium and VSTGUI pick one, juce picks the other. Juce may be wrong but the easy fix is to find all the places with a fill and a style and make them coherent.

I think, other than new assets and new colors, that's the only remaining svg issue correct?

[mkruselj]

@baconpaul There's also the issue where the slider grooves render quite differently (no semitransparent triangles) in JUCE vs 1.9. Is that the same conflicting color thing?

[baconpaul]

I'm assuming it is yes. Here's a fragment from bmp00154

 <path
     d="m 144,35 h 113 v 2 H 144 Z"
     id="path50926"
     fill="#070403"
     fill-rule="evenodd"
     stroke="none"
     style="opacity:0.08;fill:#fffefe;fill-opacity:1" />

same problem

[mkruselj]

Gosh darn it! Oh well, gotta manually tweak.

[baconpaul]

wonder if i can write a script to find em
there's probably a few.
or just remove those fills and check also - that may be easiest.

[baconpaul]

yeah i you just remove the conflicting fill and fill-rule the style gets used properly
so "if there's a style with a fill and a fill, remove the fill to work in juce" seems to be the rpescription

[baconpaul]

by the way, do we know if we will have royal updated for xt1? If so I need to update the pipelines.

[mkruselj]

I gotta talk to Nick. I think the problem will be the temporary coded multibutton you coded, all of them look a bit different style wise in Royal, so the coded ones would stick out like a sore thumb.

[baconpaul]

Right so we would need backgrounds blank for some since they change their label as we undertake actions if we went with svgs, or we would need to change the drawing code with more options

[baconpaul]

Alldone except for the goobits moved to #5437