Rock around 0.48: Interview with Inkscape team
Interview with Inkscape developers and Google Summer of Code students on release of 0.48, upcoming features in 0.49 and more.
Past, Present and Future
Joshua Andler has been active in the project since very nearly beginning of the project in 2003. This is the third time he's doing the job of release warden for Inkscape and, apparently, more or less being team leader.
Joshua, the project has gone through times of very long release cycles, over a year long in some cases. However this time it's less than a year between 0.47 and 0.48. Is there some kind of new release policy? What kind of changes should we expect in that regard and what changes should we expect in 0.49?
We really don't have any official release cycle policy. It was determined a while back that 0.49 would be another, more lengthy, refactoring cycle. Given the planned longer cycle for 0.49, an informal goal of mine was to get something new and fresh out quickly for our users. Inkscape 0.48 will be maintained with point releases as necessary while everything for 0.49 is ironed out.
The D-BUS branch from a last year's GSoC project has been merged in 0.49, and this is one of the many things being looked at for that development cycle. The primary issue has been D-BUS on Windows, and thanks to some research done by the Inkboard-NG project, we theoretically have a path forward.
Apart from that will also have to merge code from other GSoC projects we already have and the work on linking and embedding bitmaps done by Lyon Politechnique's students. 0.49 development cycle will also be the right time to see what libs we have internal copies of that we can possibly purge for proper linked libraries. The way Inkscape writes its SVG needs revisiting too: for instance, it should stop writing unnecessary SVG data when it's not applicable. And, of course, there is always a number of bugs that should be fixed.
It looks like half of the initial core team is not quite active any more. At the same time a lot of functionality is written during Google Summer of Code projects. I've noticed that Inkscape has a very high rate of returning GSoC students who also work beyond their projects. Therefore would it be correct to say that there is a new core team shaping up thanks to GSoC?
Some of the initial core team for Inkscape branched off to work on lib2geom, so they're still indirectly involved with Inkscape's development. Additionally, some of the initial core team also no longer have any "itches to scratch" with Inkscape, so they're less active in development.
Google's Summer of Code has been a fantastic resource for finding the "next generation" of core developers and contributors for Inkscape. With the "new blood" comes new itches, new perspectives, new needs, and levels of excitement and motivation that tend to wane for most developers over time.
From what I can tell Inkscape started as an SVG editor with a strong bias towards screen graphics design, which is why it is now standard de-facto for icon design and branding projects on Linux desktop. However since last couple of years there is a strong technical drawing trend: much better snapping (especially in 0.47 and 0.48), more grids, DXF importing and so on — something rather associated with Microsoft Visio and Corel DESIGNER. Is there some kind of product vision that tells the team where to stop and where to elaborate?
I would say that the project vision is to be the best SVG editor out there. Each developer's personal vision is a different story though. Some of the more technical features really are due to certain developers having their own needs than it being focused on what the community desires or needs the most.
Realistically, you get better quality code and better maintenance of code, if the developer has personal motivation. I'm hopeful that we will see more focus on SVG compliance and features in the future.
One thing that seems to confuse a lot of people is Inkscape's version number. A lot of users come with Adobe Illustrator and Corel DRAW background, where v0.something is unthinkable as production ready application. What is the team's view on that?
The project has clearly stated that a major influence to Inkscape versioning is how much of the SVG specification we support. Right now as an SVG authoring tool we're nowhere near the criteria to meet a "1.0" status. However, as just a vector illustration tool we would be far beyond 1.0. I think that we will most likely revisit our numbering plans when "0.50" is due [as we're unlikely to hit the current goal for it with the way development has been focused].
Several people in the community do a lot of work related to bug reports: sorting and defining priorities, assigning tags, requesting more detailed reports and so on. One of these people is Nicolas Dufour.
Nicolas, what can you say about community's involvement into beta testing of the new version?
Nicolas: I feel there's no (or very few) extra activity when we release beta versions. Most new bug reports filed during beta phase are related to the latest stable version, and developers have to rely on the Inkscape bug team, other Inkscape developers or hardcore users to get feedback on their recent work.
End users probably prefer using stable versions to testing beta ones, and its easily understandable, particularly when they use Inkscape as a professional tool. But it's problematic, because in the end they run into bugs of the new features only when the new version is out. Releasing minor versions more often as we do now could be a solution, even if it resulted in extra work for the Inkscape team.
I've noticed that users tend to believe that projects like Inkscape, GIMP or Scribus are very well organized, have lots of active contributors who already know about the bugs they might discover (I have to admit I also had shared this myth before I got involved into the Inkscape project). Sadly this is not the case, and we must encourage people to report bugs (or add their vote to existing ones). Every little contribution, even if it's a minor bug or a duplicate, is valuable. And it might be (why not?) the first step toward a greater involvement!
Google Summer of Code Projects
Inkscape had three successful Google Summer of Code projects this year that dealt with performance either way. The students are: Krzysztof Kosinski, Vangelis Katsikaros and Abishek Sharma.
There have been several attempts to improve Inkscape's performance before, successful and not very successful. You have been attacking the issue now from two angles. Could you please elaborate a bit on your work: what exactly you have managed to do over the summer with your respective GSoC projects?
Krzysztof: One of the performance bottlenecks in Inkscape is rendering. So far Inkscape was using its own rasterization and geometry library called Livarot. Unfortunately, this library is poorly documented, not very fast and written in rather sloppy C++, which makes it relatively difficult to improve. It also doesn't attempt to do any hardware acceleration. The computational geometry part of Livarot has been mostly replaced by a much nicer library called 2Geom, but the rasterization part is still used.
Meanwhile, the Cairo graphics library is becoming the 2D drawing API of choice for GTK-based applications. The upcoming stable release is likely to contain an OpenGL accelerated back-end, called cairo-gl. We decided that in the long run the best course of action is to switch to Cairo. It was also the subject of my GSoC project this year.
During GSoC I completed the Cairo renderer, including filters. All filters now make use of multiple processors via OpenMP. The performance of some filters has been substantially improved, most notably the Morphology primitive is far faster than it was. The Cairo port of Inkscape helped to identify several rendering quality issues in Cairo and I'm now working to resolve them.
The switch to Cairo already shows some performance improvements —Pixman, Cairo software renderer, is faster than Livarot. For solid shapes the speedup is around 50%, while for gradients it is higher.
After fixing a few rendering quirks introduced by the move to Cairo, I'll start working on hardware-accelerated filters using OpenCL. Coupled with the cairo-gl backend and the OpenGL-OpenCL interoperability features, this could allow us to run the rendering process entirely on the GPU, with the pixel data never touching main memory.
While OpenCL is typically regarded as a GPU computing API, there are OpenCL drivers for x86 processors available from AMD that also run on Intel hardware. OpenCL filters could therefore improve performance even on computers that don't have fast graphics cards.
Vangelis. My project is about selecting what needs to be rendered and rendering the selection. Inkscape selects, from all the available shapes in the file, the ones that intersect with user's window. Then it renders them on screen. Effectively selecting objects, from a 2D plane, is a problem already solved in GIS database systems, and the family of R-Tree indexes is a widespread solution.
This project aims at applying the R-Tree, or maybe another simpler indexing technique in Inkscape. Currently, Inkscape performs a full scan of the file's objects to find what needs to be rendered. This search, of course combined with the actual rendering, can slow down Inkscape considerably. This is more noticeable in large files (a common example is files obtained from OpenStreetMaps).
So far, I have been digging in Inkscape's internals to find out how the rendering is performed and where the index is needed. I have used a the library "spatialindex" which is also used in the Python's "gispython" project. I hope that in the middle of the next month I will have code ready for the next release.
Users tend to appreciate things like new features and better reliability, but they mostly have no idea about work on internals of an application and how it affects the whole thing. Abhishek, could you please tell us about importance of your GSoC project and what you've managed to achieve?
Abhishek: For complicated applications it is best to separate functionality into modules and make them communicate to each other. The current Inkscape's codebase doesn't have totally separate modules for different kind of functionalities, and my GSoC work tried to introduce such environment as far as possible. This was the first part of my project: the first portion of my GSOC work — C++ification of the Inkscape's codebase, specifically SPLayer.
The second portion was privatizing the XML nodes. Every SVG document we generate through Inkscape is nothing but an XML document that Inkscape modifies. Currently that XML is loaded in the form of a tree inside Inkscape, and many areas of code have access to many portions of that tree. The interesting thing is that as soon as we introduce parallelization, functions running in parallel start getting simultaneous access to same elements of that XML document. Therefore we needed to make different functionalities *private* to specific functions, so that only some particular functions would modify some particular chunks of the SVG, not all at once. My mentor Jon and me decided on an approach to introduce privatisation in XML nodes corresponding to which we will be having a wiki page soon enough. This was the second part of my GSoC work.
From Manual to Programming
To most Inkscape users Tavmjong Bah is mostly known as author of a quite comprehensive manual in English that he keeps updating for every new release, even though he actually contributed some code in the past.
Tav, for v0.48 you contributed massive improvements to the Text tool, including much anticipated numeric input for kerning, tracking etc. How does it feel to work on a major feature after all this time?
Great! It's true that my involvement with code has increased over time. I first looked at the code when I needed to figure out how some things worked to document them. Over time, I became interested in fixing things that I believed were key problems (e.g. PostScript and PDF export), the kinds of things that would be deal breakers for someone interested in using Inkscape.
The main thing that has impeded working on the code is it's complexity. In the past I've fixed things that needed touching only one or two files so it wouldn't be too hard to figure out what is going on. The code is in general very poorly commented, and when you do see comments, they are usually of the form "Fix Me". Working on the Text toolbar was a step up in difficulty.
Do you think you could put this experience of working on major feature to a good use by working on something else again?
Definitely. At the moment, I am interested in working on making Inkscape produce more web-friendly SVG.
During Libre Graphics Meeting 2010 that was held end of May in Brussels some active community members and developers met, many of them for the first time: Johan Engelen, Jasper van de Gronde, Ivan Louette, Elisa Godoy de Castro Guerra, Cedric Gemy, Tavmjong Bah, Felipe Sanches.
LGM2010 seems to have best Inkscape team presence since 2007, and it looks like it was also the first time most of you met each other in real life. What direct and/or indirect, in your opinion, impact has this meeting on the development process?
Jasper: A better understanding of some of the other developers and users (!) of Inkscape. Also, having been able to talk to some of the people from SVG WG made for a better mutual understanding. For me it has become clear for example that they see SVG also as a true "editing" format, which could lead to integration of things like layers in SVG.
Johan: First time LGM for me, and also first time that I met any Inkscaper in real life. For me, it inspired me to work more on Inkscape again. The last months/year my activity decreased a lot. Having heard new ideas, and meeting the people I only know digitally really inspired me to spend some more time on Inkscape. It was also interesting to see/experience the open source graphics community. Direct impact is on ideas for PowerStroke LPE. I discussed with Jasper that we could work together on diffusion curves, but we have not had contact about that since the conference.
There was a workshop organized for beginning Inkscape users during the conference. How did it go?
Elisa: It was interesting for me, because we managed to do so much: see how other people work, what background they come with and what they Inkscape for, show what could be done with Inkscape, answer all kinds of questions. I was also glad that Jean Ghali of Scribus project came to explain how to use Inkscape in conjunction with with Scribus.