On Wed, 2005-07-20 at 13:05 -0300, Santiago Roza wrote:

OK, it was just a suggestion; I guessed it would be possible (with some coordination) that all teams (Inkscape, Gaim, GIMP, etc) agreed on standardizing over one GTK bundle, and linked to it dynamically.

Of course I wasn't suggesting you guys made the distribution less reliable; I just thought my suggestion didn't have to cause that, necessarily.

Totally, I didn't read your email like that. Any suggestion is a good suggestion :)

Santiago, we really appreciate your suggestion and comments. Some of us have talked about working on a standard GTK bundle and installer for WINDOWS before, and is something that should be continued. If you have experience with this, or want to work on some GTK bundle/installer for windows which GIMP, GAIM, Inkscape, etc, could use, I think that would be a valuable contribution and once available, would provide a major debate (and probable use) by the apps you discuss.

NOTE: This would be something that could be worked on with the upcoming CREATE project...and/or at least discussed in a shared space. Both the GIMP and GAIM don't just bundle GTK, but install their own GTK version (which is part of their NSIS Installer), so I have gotten by with only installing one GTK before which can be used by both...cool!

Sincerely,

Jon

I think this is a much bigger issue than the current Inkscape release - but maybe some here are in position to help coordinate between the differnet gtk family groups. There are more than a few of us dealing with this - it seems like over 10% of the posts on the gtkmm developers list are about library/installation issues and it also seems to be a big issue for Inkscape release packaging. The problem stems from many independent library dependencies, different releases, and different version nos.

Regardless of the platform, we have found the biggest hassle of using gtkmm is the whole library dependency and management issue - it's a mess - we cannot even keep track of what versions of the different libraries we have on our few linux boxes - much less what we're including on our Windows builds (packaging the glade library set and the gtkmm set) or OSX builds. We know we're somewhere on the 2.6.x series - but even I can't say exactly where on each machine and that is no way to manage software QA. Hell, I can't even find one place that lists all the gtkmm dependencies and current matching versions.

Windows seems to have managed the shared dll hell problem by having very, very few, and more carefully controlled/tested releases, however, that seems to be a less desirable approach than frequent upgrades. Somehow I think a more unified gtk/gtkmm "studio" release approach is needed so that all the major dependency libs are "packaged" (even more than what Debian does) including glib, gtk, pango, libsigc, libglade, gtkmm, etc, etc. Then we know whether we are using "gtk development studio" 2.4.4 or 2.6.7 or 2.7.1 or whatever and all is well with our matching dependencies. Sure, it will not be or is not easy to coordinate all these different gkt related projects or personalities but once we have this organized, then we can better control and package which "studio lib package" our apps work/ship with. Heck, maybe there is even a opportunity here for a group to package all this the same way Red Hat, Debian, etc packages all the kernel dependencies, maybe we need something like "Gtk Core 8" :)

bulia byak wrote:

On 7/20/05, Santiago Roza <santiagoroza@...400...> wrote:

...

OK, it was just a suggestion; I guessed it would be possible (with some coordination) that all teams (Inkscape, Gaim, GIMP, etc) agreed on standardizing over one GTK bundle, and linked to it dynamically.

I think the most realistic is a combined package of Inkscape + Gimp for Windows, and if this is realized it will make sense to use shared libraries in it.

On Wed, 2005-07-20 at 22:41 -0700, Bryce Harrington wrote:

On Wed, Jul 20, 2005 at 02:49:18PM -0600, John Taber wrote:

...

I think this is a much bigger issue than the current Inkscape release - but maybe some here are in position to help coordinate between the differnet gtk family groups. There are more than a few of us dealing with this - it seems like over 10% of the posts on the gtkmm developers list are about library/installation issues and it also seems to be a big issue for Inkscape release packaging. The problem stems from many independent library dependencies, different releases, and different version nos.

Windows seems to have managed the shared dll hell problem by having very, very few, and more carefully controlled/tested releases, however, that seems to be a less desirable approach than frequent upgrades. Somehow I think a more unified gtk/gtkmm "studio" release approach is needed so that all the major dependency libs are "packaged" (even more than what Debian does) including glib, gtk, pango, libsigc, libglade, gtkmm, etc, etc.

Yes, I definitely agree. After all, we're application developers first, package distributors a distant second. We need to be looking for ways to move that responsibility upstream, as we've been able to do with the unix packages. We used to put great attention into crafting debian, gentoo, rpm, etc. packages each release for each distro, but as time has passed and as we've gotten into more and more distros, today we are able to mostly leave that work to the experts and focusing on just putting out a good core package. Being able to take that same approach with the Windows package would sure simplify things; consider how much trouble the Windows build has been this time through, and the extra work required for testing and fixing it up. If another group were able to take the responsibility for this, it would simplify our release process and enable the Inkscape releasers to focus even more on the software, rather than the packaging.

Another thing that I have noticed here at desktopcon.org is how many times developers talked about shifting generalizable solutions upstream. Carl Worth mentioned this much about his style of dev. with Cairo. This really makes sense to me in this case as well. (CREATE project anyone?)

Jon

On Thu, Jul 21, 2005 at 10:44:49AM -0600, John Taber wrote:

Jon and Bryce, When you get a chance on your return from the conference, could you post a quick recap of status and future of the progress Carl Worth and Keith Packard are making on the Cairo SVG backend ? Is it now as good as the livarot/Inkscape renderer or as librsvg ? And speed? Thks.

Here's a recap of the Inkscape, OCAL, and Cairo talks at DDC and OLS. I'll probably miss some important bits so I'd appreciate it if Rejon or anyone else that attended could fill in any holes.

Most of the presentations at DDC were about Xorg internals, which oddly didn't have many visuals. There were some presentations on libraries, and a few applications. The conference ran for two days.

My talk was in three parts: A presentation (using inkview), a live demo of inkscape, and a slideshow displaying some of the artwork that people have done. I've posted my files here:

http://www.bryceharrington.com/Present_desktopcon/

I think my talk went fairly well. I briefly explained what SVG is (I suspect most of them already know what SVG is), then explained where Inkscape came from (Gill and Sodipodi), and gave a quick rundown of a few of Inkscape's features (I borrowed Ted's SCALE slides for this).

Next, I did a demo of the new features in Inkscape, showing off the basic shape editing, all the new text capabilities, node editing, patterns, clones, booleans, and so forth.

I showed a few of the about screen submissions and a collection of Inkscape art I got from DeviantArt. I think people really liked this part of the talk. :-)

Finally, I explained some of the issues we've noticed among the community, such as the need for better SVG support in OOo, better PDF export from Inkscape (Keith Packard and Carl Worth were quick to shout out 'switch to cairo!'), and some of the rendering issues that librsvg users were finding. I also listed some of the near/mid term objectives from our roadmap, including the work that the SoC students are doing and some of the other projects that are on our wishlists.

There were a few questions from the audience. One person asked if by "full SVG support" we really meant full SVG support, including Javascript and animation; the answer was yes, full SVG support is Inkscape's primary objective. We already have the ECMA interpreter in the codebase, but need to do some DOM work to allow us to hook this up fully. Animation is probably further out, but definitely something we intend to add in at some point. There was a question I didn't quite understand about file sizes efficiency between SVG and raster; Pat Suwalski answered the guy's question. I also tried to explain that vector and raster image formats are really for different purposes, not really alternatives as much as different ways of representing artwork.

Jon Phillips had the last presentation of the day, and I could see that people were really tired and mostly had their heads buried in their laptops. However, I quickly saw that Jon is a *damn* good presenter and gave probably the best presentation of the whole conference. He cajoled the audience out of their laptops joking about all the "dry Xorg talk" and that the OCAL talk would be light and easy. By the end of the talk I don't think there was a single person looking at their laptops!

Jon explained about how the Open Clip Art Library is all about building up a community resource of graphics. The origin of the library was with the Sodipodi Flags Collection that Uraeus ran, and that directly inspired the project. Jon explained the philosophies of Creative Commons and Public Domain, and discussed with the audience about why the commercial clipart packages can be problematic, and about what Public Domain meant and why for clipart it is so important. People seemed to fundamentally grasp the importance of the project and I saw a lot of people nodding with the points Jon was making.

One person asked if there were copies of international symbols, and Jon showed that there were quite a few. Someone else asked about icons, which Jon showed. There was some talk about interfacing to the library, DMS, and other projects that allow for viewing of the images.

In addition to Inkscape and Open Clip Art, there were several talks on Cairo of relevance to us. Carl Worth gave a presentation that focused on the life cycle of a bezier curve, explaining how the points in the curve and the stroke width are defined, how the renderer renders this information, and the types of flaws that can be found from various corner cases.

He demoed the issue in Inkscape by drawing a bezier curve and setting its stroke width extremely high, and then moving the end points around. The effect was that the end cap for the line got erratic, and occasionally 'spiked' outward. He explained that the cause for this behavior was that at such large sizes, floating point approximations became significant. The renderer was rounding point locations and placing corners such that it left "gaps" in the boundary of the line stroke; the filling algorithm thus essentially "leaked" through the gap, causing paint to extend beyond the end of the line, and other strange effects. (I'm sure I've totally butchered the description of this bug.) I don't think this is a huge issue for us because a) it only seems to occur when you set the stroke width to insanely high settings, and b) it'll presumably get fixed when we switch to cairo.

I also found the talk on liboil of relevance to us. liboil is David Schleer's "Optimization of Inline Loops" library, that packages a variety of assembly routines for performing low level mathematical operations, many of which are highly relevant to graphics programs. David is a lead developer on GSStreamer, which is the primary motivation for liboil, however there is also strong interest in seeing this library incorporated into Cairo to help jazz up Cairo's rendering performance. David requested that developers send in their assembly routines to be considered for inclusion in this library, so that all of us can benefit from sharing a common pool of code. I passed him a link to Inkscape's MMX code in libnr.

On Friday, Carl Worth gave a Cairo tutorial. He went through the Cairo API and explained what each function did, and we played with several example files to see how to draw shapes, write text, and so on. He showed how the same code could be used for drawing to the screen as well as to generating postscript output. The tutorial plus the required dependencies are posted here:

http://cairographics.org/snapshots/

It was a very enjoyable tutorial. I learned a ton and found it quite inspiring. After the tutorial I browsed through the Inkscape codebase and got a little bit of an idea on where Cairo would plug in, and what sorts of changes would be needed to get us there. Migrating to Cairo looks like a lot of work, but it also sounds like it'll be quite fun.

Cairo is still in heavy development, and the focus to date has been on getting correct results moreso than optimization. I got a copy of ScislaC's Gaze SVG image for use as a stress case, and Carl and I tested cairo on it, and compared its rendering and performance with Inkscape. Cairo rendered the file badly, making ScislaC's fairie look like some undead creature. Carl found out that this was caused by a small bug in Cairo, which he's now fixed, and the image renders well. Carl measured that it took 48 seconds to render this with Cairo, compared with around a second or so by Inkscape. Carl will be able to use this file as a performance test case, with the objective of getting the performance down within range of Inkscape. He feels confident that between liboil and some profiling, this should be very doable.

I don't know if there has been very extensive comparisons of livarot and cairo, but my own tests and the informal testing I've seen others do seems to indicate that cairo is pretty close to livarot in terms of rendering functionality, however I'd want to see much more testing before we can say for sure. I'm confident that if any differences do emerge, and if cairo is found to be incorrect, the issues are going to get fixed swiftly. I don't think Cairo would be a drop-in replacement for livarot; I think there is additional code that livarot (and libnr) has that is out of scope for Cairo, that we'd need to repackage somehow and use, but it will take some investigation to identify what these things would be specifically.

The big news at the conference was the integration of GNOME/librsvg and cairo. Several people were experimenting with use of cairo for rendering the desktop widgets and such. Currently, it appears that Cairo development is heavily focused on supporting these efforts. Thus, Cairo seems to have reached a point where it is a viable replacement for the libart-based rendering code in librsvg, and work is progressing with that goal in mind.

However, note that the librsvg SVG backend that is under development isn't precisely what we'd need for Inkscape. The 'r' in rsvg implies that it's designed for single-pass-through rendering such as is needed for static SVG displays as you'd need for widgets and desktop stuff. Since Inkscape is an editor, what we need is a 'dynamic' SVG renderer, that allows us to interactively alter the drawing as the user moves things around, adds new drawing elements, updates style definitions, and so forth.

The good news is that Cairo itself is designed as a dynamic drawing library. It does not hold state on the items being drawn, and depends on higher level code to track the drawing elements. Thus, what we'd need to do is establish something like Inkscape's Repr and shape hierarchy, but have it render by making cairo calls instead of libnr/livarot calls. I think this will touch a LOT of the Inkscape code, but on the plus side by replacing the rendering code it should really cut down the amount of code we will have to maintain inside Inkscape.

One other point of interest was in Keith Packard's presentation on TWIN. TWIN is an extremely trimmed down version of X11 that runs on embedded devices. Apparently, the night before the talk he needed a logo, and Carl told him to "use Inkscape!" so Keith grabbed an image of the constellation Gemini off images.google.com, imported it into Inkscape, and manually traced out his logo no prob. Looked great, too. :-)

I was glad rejon and I were able to attend the conference. I'd definitely encourage other Inkscaper's to go to it next year, especially if they can present. I think this would be good place to present about development work you're doing on Inkscape. Also, demoing Inkscape was a lot of fun, and I'd strongly encourage others to demo it at other conferences if you get the chance.

Bryce