Attempt to add Conical Gradients & Spiral Gradients to Inkscape's Fill & Stroke options

Bug #346681 reported by Jacob M. Carson on 2009-03-22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Nominated for 0.46.x by pierluc
Nominated for 0.47.x by pierluc
Nominated for 0.48.x by pierluc
Nominated for Old by pierluc

Bug Description

This is a .diff file containing code that allows Inkscape to generate spiral gradients, as well as conical or angular gradients as a degenerate case. It allows the user to create and edit these gradients with the gradient context (tool) and the Fill and Stroke dialog in the same manner as a Radial gradient. It also includes an (ugly) icon for use in the Fill and Stroke dialog and Gradient toolbar.

Although I believe it is functional as-is, there are some improvements that could be made before declaring it "perfect."
[1] The on-canvas knot interface is exactly the same as the interface for Radial gradients. Although usable, the gradient stops shown don't correspond to the color positions on-canvas. Making a distinct knot system would allow this and other features below.
[2] There is currently no option to make the gradient spread for anything less than a full rotation.
[3] Because of [2], the Repeat/spread options -- none, reflected, direct -- have no effect.
[4] There is no method to change the direction of the spiral's rotation.
[5] No effort is made to inform the user that spiral gradients are not part of the SVG standard, and thus will probably not work with other SVG implementations.

Jacob M. Carson (reneviht) wrote :
Jacob M. Carson (reneviht) wrote :

This is a minor improvement on the previous patch:
[1] Spiral Gradients can now change direction, as described in [4] in the previous patch
[2] Spirals can now be linear in radius, as well as exponential.


This is wonderful work and something everybody's been waiting for, for ages :)

However there is a very sad thing about this patch: it introduces a new SVG element that will make compatibility not possible and provides no backup rendering.

I'm pretty sure that you will be contacted by more experienced team members soon to comment on the patch in details, I just wouldn't want you to think that we never noticed your contribution ;-)

Jon A. Cruz (jon-joncruz) wrote :


Thank you for this code and effort. As seen in discussions on the mailing list, though, one key point for Inkscape is to keep the SVG files standard and renderable an any compliant SVG viewer. So we would need to get this reworked in the underlying approach to meet that goal.

Jaspervdg (jaspervdg) wrote :

On the following Wiki page I've started documenting alternative (non-bitmap) means for simulating (conical) gradients in SVG:


Jasper's work looks really good now. Would you be interested in reworking your patch to get it included to 0.47? We are wrapping up to release it really soon.

Jacob M. Carson (reneviht) wrote :

Thanks for your interest in my code.

I would love to be able to rework my patch to make it viable for Inkscape. However...

First, there are two things you could mean by that. The first (and most likely) is that I should change the spiral gradient so that it simply implements Jasper's code directly. The second is to make Jasper's code the "backup rendering" somehow. This may be made clear in the mailing list; however, I have not subscribed to said list, and I couldn't find backissues in the places I looked.

Second, there's a lot more one could do with Jasper's code than what little I've done. If Jasper's code renders quickly, restricting that sort of thing to spiral gradients would be wasteful; it would make more sense to come up with a more general editor for fills of that type. If Jasper's code doesn't render quickly, then I'm not really interested in using it; the primary reason I use gradients instead of clipped/masked blurs is because the blur filters slow down my computer.

I would test it myself to see which hypothetical applies, but that leads to the third problem: When I click on the link Jasper provided, all I get is a page that says

Database Error: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    (SQL query hidden)

from within function "MathRenderer::_recall". MySQL returned error "1267: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (".

I saw the page once before, but I don't remember it well enough to implement Jasper's code.

On the off-chance you were waiting to hear from me before some part of the wrap-up, well, I won't be able to do anything in time. Best go ahead without me, and sorry I disappointed you.

Please forgive the lateness of my reply.

Jaspervdg (jaspervdg) wrote :

Sorry for taking a while to reply (hadn't subscribed to the bug yet). There were some technical difficulties with the math used on the page, but these have been taken care of and you should now be able to view it properly.

As for the speed of the approximation I made... It's slow. There would definitely be ways of letting Inkscape render such filters faster, but that obviously doesn't help for now. However, this need not be a problem. For simply viewing the image (or exporting it to png) it's not so bad, so if we can somehow make it so that Inkscape marks the filter as specifying a conical gradient and renders it accordingly we could have interactive editing in Inkscape and a non-bitmap fallback in other renderers.

I agree that it would be interesting to explore generalization of this concept btw, but I guess we have to start somewhere.

The main drawbacks of the filter fall back as opposed to the bitmap fall back in my mind are that bitmaps are much more widely supported and that there are some quirks in (at least) Batik's implementation that would require some further attention. Also, the filter solution is considerably more complex.

su_v (suv-lp) on 2009-09-23
tags: removed: angle angular cone conic fill render spiral stroke
su_v (suv-lp) on 2009-12-04
Changed in inkscape:
importance: Undecided → Wishlist
tags: added: patch-rejected-upstream
Jaspervdg (jaspervdg) wrote :

Actually, as far as I'm concerned the patch isn't necessarily rejected. It's a shame it has come to a halt, but in principle if at least some fallback is implemented (either bitmap or filter based) it would be fine to put in.

Pablo Trabajos (pajarico) wrote :

Well, i'm just guessing :). Feel free to change it.

Pablo Trabajos (pajarico) wrote :

My rationale is that, provided the feature gets merged into SVG standard at some point, the changes to the patch would be too extensive to add them. I thought the patch was heavily based on bitmap fall-backs and a native implementation would take another way when implemented. But I guess there are parts which could be re-used.

I thought this was similar enough to #170049, under the same 'patch-rejected-upstream' tag.


Pablo Trabajos (pajarico) wrote :

Full disclosure: I'm not a programmer

ScislaC (scislac) wrote :

To the original submitter of this patch:

I am going to close this report as Won't Fix, primarily due to the reasons listed above about compatibility with the SVG spec. However, all hope is not lost. There is currently work being done in a branch to add mesh gradient support to Inkscape, and the work is being done by an invited expert to the W3C, as mesh gradients have been accepted for SVG 2.0. A side benefit of this is that other types of gradients (such as conical) will be able to be achieved using meshes, and UI for conical gradients is indeed planned as well.

Find out more at:

If you feel that this report was closed in error and should be reopened, please go ahead and do it with a comment as to why.

Changed in inkscape:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions