Mesh gradients in Cairo now official

Mesh gradients in Cairo now official

Did you ever wonder if free software such as Inkscape is going to get mesh gradients for impressive photorealistic graphics? We have some good news for you.

A new stable version of Cairo 2D vector graphics library has just been released with support for mesh gradients that allow creating complex color transitions and lighting effects. Here is an example created by Tavmjong Bah with his mesh gradients branch of Inkscape:


For Inkscape this public release of Cairo makes the mesh gradient branch one big step closer to becoming part of v0.49, even though there's no final decision on this yet. It will also make conical gradients possible. In fact, it's already available in the branch:

Conical gradient

The SVG W3C working group already agreed to make this feature part of the SVG2 specification. You can read far more technical details about the implementation on Tav's website. Currently there are no builds of the mesh gradient branch that we are aware of.

For Scribus it's also important as it also has a basic support for mesh gradient fills for ca. 2 years — both creating, editing and importing from PDF and AI files. In fact, it was the first application to make use of this new Cairo feature. It's most likely that Scribus 1.5.0 will have this enabled by default.

But the new version of Cairo has even more improvements, especially in terms of performance. Cairo also make it possible to switch between levels of antialiasing (none, fast, good, bad) to finetune performance. The OpenGL backend was ported to GLESv2 and received even more love.

Finally, there are some useful API changes in this release such as being able to address any surface as an image for direct modification of the raster data, as well as foundations of deferred rendering.

For complete release notes please visit this page. Most curious users can download and compile Cairo from source code. Scribus from SVN trunk already ships a local copy of Cairo, albeit it might need an update.

Was it useful? There's more:

4 Responses. Comments closed for this entry.

  1. Wow… Mesh in Inkscape?
    Would be AWESOME!

  2. I’ve grown more and more interested in how one should go about contributing financially towards efforts like these.

    I can of course contribute directly towards the project but I’d also like to target specific development within the project that would benefit me in my work as a designer.

    This is, by far, the most effective way I can further the development of any application since I’m firmly within the category of users who are actually using Inkscape to work more effectively in my day-job.

    Is, or similar the way to go? It would be cool to tally up the various parties interested in specific features in Inkscape. My guess is that anything towards easing the creation of screen-based graphics has a larger user-base than anything towards print. Stuff like improved slicing, export of jpg in addition to exporting SVG-slices (new feature :) ).

    Furthermore, I think that it’s worth trying the same approach towards fixing long-standing issues, like freely editable page origin or dynamic linking to other SVGs.

    I’d even be willing to chip in specifically to get for example, a simple way to swap one linked image with another by.

  3. Kevin Brubeck Unhammer 26 March 2012 at 2:27 pm

    JimmyVolatile, I’d say pledging to the LibreGraphicsMeeting would be a good start.

    I’m not sure how useful it is to pledge towards a specific feature, in that case you need at least an available developer who is deeply involved with the project and thinks it is a worthwhile and possible feature. This is not always the case …

  4. Yes. I agree it’s really a good start to sponsor annual meetings for developers and users, and I’ll certainly continue doing so, especially since all talks are available from Digital River shortly after the event.

    At the same time, I’m just trying to dream a little further. Trying to see how also end-users with common interests could contribute financially towards meeting their specific needs. Usually, this kind of structure exists within a company or some tightly knit group. The trick might be to allow more disparate individuals to form ad-hoc financial support for specific, everyday features. These features may not be the most innovative or fun to program but are still needed and should be rewarded accordingly. Think of it as a “wish-list” where each sought-after function carries a price tag proportional in size to the number of people who desire it.

    It’s really a true “Vote with your wallet”-concept.

    Now, how this should take place is a separate discussion but maybe some form of Google Summer of Code model is desirable, where the candidate has to provide some proof of concept before part of the reward is paid out?

    Or, maybe the donors get to set the requirements:
    Category A) The donors that are happy to just donate towards the cause

    Category B) The donors that require proof of concept before payments are made.

    Donations in each category would the be awarded accordingly. First the dev would get all donations from cat A, then, if he ends up creating a POC, he’ll get what’s donated in category B.

    Anyone else got any ideas?