Mesh gradient status
Hi,
I've gotten a number of queries as to when mesh gradients will be available in Inkscape. Some people seem to think that it is a project that is close to being ready... it is not. There is still a lot of work to do and several major issues to be resolved. So I though I would give a status report:
At the moment, you can create, edit, save, read in both Coons Patch meshes and tensor meshes (the latter have not been approved by the SVG working group). There are a few nice editing features available: Conical gradients, sampling color from beneath the mesh, toggling between straight edges and curves, etc. However, the code is very buggy. Expect frequent crashes. Save often. Undo does not work for most things. Revert is a poor person's substitute.
Before the mesh code can be merged with trunk the following issues MUST be resolved:
1. Meshes have been approved for SVG 2 but the syntax has not been finalized and will not likely be finalized for some time. For meshes to be included in Inkscape we will need to keep them in the Inkscape namespace for the moment and include a fallback mechanism. (Note, there are quite a few nice SVG 2.0 features that we could adopt quickly if we had a way of handling fallbacks: markers that inherit stroke color, solid colors that will eliminate the need for the one-stop gradient hack for creating a palette, etc.).
2. Meshes rely on Cairo trunk. We need an official Cairo release with the mesh rendering code. The last new Cairo release was in Sept of 2010. Who knows when a new release will be made.
3. My code is a hack. There are multiple issues that need to be resolved. The most important one is how do meshes fit into the Private/Vector structure used by linear and radial gradients (Inkscape gradients are broken up into two gradient elements, one that handles the geometric layout and the other that handles the color vector. This allows reuse of the same gradient to be applied to multiple objects. It may not make sense for meshes.) Of course all the crashes must be eliminated.
4. GUI: How should meshes fit into the GUI? Should meshes have their own tool bar? The gradient chooser is not really applicable for meshes and meshes will have lots of their own options:
* Mesh creation: * Mesh type: Normal, conical, ? * Number of rows/columns. * Mesh editing: * Show/hide handles. * Make handle smooth/symmetric.
5. Saving to PDF/PostScript needs to be implemented. (Export to PNG works.)
I am sure I've missed some.
Issues that would be nice to address:
1. Node editing. Gradients implement their own dragger code. It would be nice to be able to use the code from path editing. This would enable things like editing the paths by dragging or selecting a group of nodes and rotate/scale/etc. them together.
2. Auto generating an initial grid based on path shape.
3. Auto fitting. It would be the nice to be able to layout a rough mesh and have Inkscape adjust the mesh to match an underlying drawing. My branch can already set the mesh corner colors by sampling the image underneath which is a real time saver.
4. Auto smoothing of patch boundaries. I have an initial implementation that attempts to make color transitions across patch boundaries smooth. This can certainly be improved.
Tav
On Tue, Jan 24, 2012 at 6:51 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've gotten a number of queries as to when mesh gradients will be available in Inkscape. Some people seem to think that it is a project that is close to being ready... it is not. There is still a lot of work to do and several major issues to be resolved. So I though I would give a status report:
Would something on the website help to deter people from pinging you directly? If we had a prominent link about work in progress features and a thermometer displaying the likelihood of inclusion anytime soon in a release. This way we could have Gradient Meshes temperature showing as below freezing... not because it isn't being worked on, but because there are major hurdles in the way currently. As far as I'm concerned, something like lack of a stable cairo release would at best only allow the temperature to show as freezing, even if the feature is 100% awesome and functional otherwise.
- Meshes have been approved for SVG 2 but the syntax has not been
finalized and will not likely be finalized for some time. For meshes to be included in Inkscape we will need to keep them in the Inkscape namespace for the moment and include a fallback mechanism. (Note, there are quite a few nice SVG 2.0 features that we could adopt quickly if we had a way of handling fallbacks: markers that inherit stroke color, solid colors that will eliminate the need for the one-stop gradient hack for creating a palette, etc.).
Okay, we've discussed things needing to be in the Inkscape namespace and providing fallbacks for years. What would be the most sane thing to try and approach first? To me, the solid colors seem like it would be a decent place to explore simply because how it functions now could be the fallback. Thoughts?
- Meshes rely on Cairo trunk. We need an official Cairo release with
the mesh rendering code. The last new Cairo release was in Sept of 2010. Who knows when a new release will be made.
Not even the cairo devs know. I had tried persuading them last spring and they made it sound like they could push something some time last year... obviously that never came to fruition.
- GUI: How should meshes fit into the GUI? Should meshes have their own
tool bar? The gradient chooser is not really applicable for meshes and meshes will have lots of their own options:
Yes, they really should have their own toolbar. I really wish that GTK was more dynamic and would allow "if mode A toggled, show widget set A" type functionality for everything after selecting the gradient type. For one, if it did this, we could then condense the rectangle, ellipse, and star into one tool with a "shape type" toggle as the first widget.
* Mesh creation: * Mesh type: Normal, conical, ? * Number of rows/columns. * Mesh editing: * Show/hide handles. * Make handle smooth/symmetric.
I'm sure we'd find more too. ;)
- Auto generating an initial grid based on path shape.
It's obnoxious, but +1. ;)
- Auto fitting. It would be the nice to be able to layout a rough mesh
and have Inkscape adjust the mesh to match an underlying drawing. My branch can already set the mesh corner colors by sampling the image underneath which is a real time saver.
That sounds incredibly useful. Also, apparently I missed the mention of how to sample beneath the mesh in the main thread, I guess I need to go re-read some of it.
- Auto smoothing of patch boundaries. I have an initial implementation
that attempts to make color transitions across patch boundaries smooth. This can certainly be improved.
Is this already committed and does it actively work or need to be toggled?
Cheers, Josh
On Tue, 2012-01-24 at 10:11 -0800, Josh Andler wrote:
On Tue, Jan 24, 2012 at 6:51 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've gotten a number of queries as to when mesh gradients will beavailable in Inkscape. Some people seem to think that it is a project that is close to being ready... it is not. There is still a lot of work to do and several major issues to be resolved. So I though I would give a status report:
Would something on the website help to deter people from pinging you directly? If we had a prominent link about work in progress features and a thermometer displaying the likelihood of inclusion anytime soon in a release. This way we could have Gradient Meshes temperature showing as below freezing... not because it isn't being worked on, but because there are major hurdles in the way currently. As far as I'm concerned, something like lack of a stable cairo release would at best only allow the temperature to show as freezing, even if the feature is 100% awesome and functional otherwise.
I think I just need to include a warning when ever I post something.
- Meshes have been approved for SVG 2 but the syntax has not been
finalized and will not likely be finalized for some time. For meshes to be included in Inkscape we will need to keep them in the Inkscape namespace for the moment and include a fallback mechanism. (Note, there are quite a few nice SVG 2.0 features that we could adopt quickly if we had a way of handling fallbacks: markers that inherit stroke color, solid colors that will eliminate the need for the one-stop gradient hack for creating a palette, etc.).
Okay, we've discussed things needing to be in the Inkscape namespace and providing fallbacks for years. What would be the most sane thing to try and approach first? To me, the solid colors seem like it would be a decent place to explore simply because how it functions now could be the fallback. Thoughts?
I think this would be an excellent choice for where to start. I see all kinds of hacks in our code to make one-stop gradient work for palettes. I've held off commenting on this as the solidColor attribute has not yet come up in the list of SVG2 requirements[1] that the SVG working group is going through (it is actually the next thing on the list) so it hasn't been officially endorsed but I can assure you it has very strong support. What I think we should do is to replace all the one-stop gradient stuff with solidColor and then at the saving stage choose between saving as solidColor or as a one-stop gradient (both are types of "paint servers" so they are referenced in the exact same way) by other objects.
BTW, I mean to blog about the SVG working group. It is moving forward on SVG2 rather quickly with representatives from all the major browsers as well as Canon and Adobe. I don't think we will see a repeat of the SVG 1.2 fiasco.
- Meshes rely on Cairo trunk. We need an official Cairo release with
the mesh rendering code. The last new Cairo release was in Sept of 2010. Who knows when a new release will be made.
Not even the cairo devs know. I had tried persuading them last spring and they made it sound like they could push something some time last year... obviously that never came to fruition.
I suppose we could try lobbying again.
- GUI: How should meshes fit into the GUI? Should meshes have their own
tool bar? The gradient chooser is not really applicable for meshes and meshes will have lots of their own options:
Yes, they really should have their own toolbar. I really wish that GTK was more dynamic and would allow "if mode A toggled, show widget set A" type functionality for everything after selecting the gradient type. For one, if it did this, we could then condense the rectangle, ellipse, and star into one tool with a "shape type" toggle as the first widget.
Oh, that would be nice!
- Mesh creation:
- Mesh type: Normal, conical, ?
- Number of rows/columns.
- Mesh editing:
- Show/hide handles.
- Make handle smooth/symmetric.
I'm sure we'd find more too. ;)
- Auto generating an initial grid based on path shape.
It's obnoxious, but +1. ;)
- Auto fitting. It would be the nice to be able to layout a rough mesh
and have Inkscape adjust the mesh to match an underlying drawing. My branch can already set the mesh corner colors by sampling the image underneath which is a real time saver.
That sounds incredibly useful. Also, apparently I missed the mention of how to sample beneath the mesh in the main thread, I guess I need to go re-read some of it.
There is a paper where the usefulness of auto fitting has been demonstrated.[2] I think it would be the cat's meow. To sample underneath the mesh, select the nodes you wish to change and do a Alt-K. If a corner node is on the edge of the mesh, the sampling point is moved in a little bit.
- Auto smoothing of patch boundaries. I have an initial implementation
that attempts to make color transitions across patch boundaries smooth. This can certainly be improved.
Is this already committed and does it actively work or need to be toggled?
You have to select the nodes you want to smooth and then hit Alt-J. It doesn't work particularly well and don't do it on an edge node or the shape of your mesh edge will be changed. Note, the keyboard shortcuts where chosen because they were the first ones I found not already taken. No serious thought went into them.
Tav
[1] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input [2] http://research.microsoft.com/pubs/69442/imagevectorization_siggraph07.pdf
2012/1/24 Tavmjong Bah <tavmjong@...8...>:
- Node editing. Gradients implement their own dragger code. It would be
nice to be able to use the code from path editing. This would enable things like editing the paths by dragging or selecting a group of nodes and rotate/scale/etc. them together.
This is entirely possible and in fact I designed the control point classes with this in mind from the start. If I converted the gradient dragger to the classes I developed for the node tool, all extra node tool features, such as transform handles, would work automatically. However I'm still not sure how to tie together the node tool, the gradient editor, the pattern editor and the (to be written) shape editors.
Regards, Krzysztof
participants (4)
-
Josh Andler -
Krzysztof Kosiński -
Pajarico -
Tavmjong Bah