SVG Parser Alpha Color Support

General JUCE discussion
1

Hi JUCE team,
As we transitioned some of our graphic assets to svg it seems JUCE svg parser ignores alpha.

Here is a patch, would be nice to have alpha support add (you could also add HSL if you’re really into making it even more compatible).

svgparser_alpha.patch (2.4 KB)

6 Likes
2

Hi there,
Know you all busy but would be nice if this will get into the mainstream juce as this shouldn’t conflict and imporve JUCE svg compatibility.

3

Thanks for the patch! We’ve put this and HSL/HSLA support onto the juce6 branch here:

4 Likes
4

If you are doing bug fixes in the juce6 branch, is there any way we can currently legally use this since there is no way to buy a juce6 license yet? Am I allowed to cherry pick this into my develop branch?

1 Like
5

We’re cherry-picking juce6 bugfixes back onto develop on a case-by-case basis. I’ll move this over to develop so you can use it with a JUCE 5 license.

5 Likes
6

Awesome, thanks.

7

Looking at this fix, it seems it’s using the Colour constructor to build the HSL object. But Juce doesn’t use HSL. It’s using HSB which is different. On the surface, it might seem the same because in the English language brightness and lightness might be semi-interchangeable, but the concepts are slightly different.

4 Likes
8

Here is an example implementation:

Colour HSL (float hue, float saturation, float lightness, float alpha)
{
    auto v = lightness + saturation * std::min (lightness, 1.0f - lightness);
    auto s = (v == 0.0f) ? 0.0f : (2.0f * (1.0f - lightness / v));

    return Colour::fromHSV (hue, s, v, alpha);
}

Maybe that should be a part of the JUCE Colour class?

2 Likes
9

Thanks for the info! This is fixed here:

There are also a few convinience methods for HSL colours in Colour now.

5 Likes
10

Awesome, thanks.

1 Like
11

Thanks

12

Small OT: I’ve noticed that the commits related to HSL also drop some const qualifiers in the float arguments to various methods of Colour. What’s the rationale behind that, given the fact that those values aren’t changed in the method body?

13

The const is redundant since the function parameters are by-value.

14

Uhm… when it’s in the declaration, I’d agree with you that it doesn’t matter.
But in the definition of the method, where const can be present regardless of whether it’s there in the declaration, I think it has a useful purpose: to prevent the body of the method from inadvertently changing a value that’s not meant to.
It’s exactly the same rationale behind the declaration of const local variables.

15

The JUCE coding standards contains the following paragraph:

If you have a local variable or function parameter which is not going to be changed then you should consider making it const. But the factors to consider here are that adding const makes the code more verbose, and that may add unnecessary visual clutter if the constness is unimportant or obvious. Or it could be a positive thing if it’s useful for the reader’s attention to be drawn to the fact that this variable is constant. A general rule is that in very short block of code, don’t worry about making local variables const. In longer blocks where a variable is used many times, you may want to make it const if you think it’s a helpful tip to the reader. Note that In almost all cases declaring a primitive value as const makes no difference whatsoever to the compiler’s code generation.

I’d argue that in these cases, the constness of the function parameters is unimportant and the code is short enough that it’s unnecessary - it just ends up being visual clutter when you’re scanning the code.

7 Likes