- Inkscape Devel - Inkscape Mailman

NEW: cairo rendering in outline mode
by bulia byak 04 Mar '07

04 Mar '07

I was curious if cairo is in fact slower or faster than our current renderer. I didn't feel like converting us totally to cairo yet, but we have outline mode which is much simpler and perfect for tests like this. So in about 3 hours (of which 2 hours were spent figuring out a known bug in cairo) I converted our outline mode rendering to cairo. The result of this experiment, after I adjusted the tolerance of cairo to match our outline mode quality, is near parity. That is, cairo is about as fast as our own renderer, at least for outline mode (i.e. lots of paths but no gradients or transparency). However this claim needs to be qualified: - It is only true for the latest version of cairo (tested with 1.3.14). Versions 1.2.x are noticeably slower. - This uses image backend to render to a memory buffer, and therefore cannot use any hardware acceleration. Using hardware-accelerated backends will require much more drastic changes in Inkscape's architecture. - Even with image backend, currently cairo is used _only_ for path rendering, each path going to its own temp buffer, and these buffers are later composed together just as they were before. I suspect that if this is optimized by allowing a single cairo context draw all of the paths in the drawing into a single buffer, performance will improve noticeably. In any case, since this does not make for any speed regression, and since it fixes at least one bug that our native renderer had in outline mode, I committed this. Please test outline mode thoroughly and report if you find any problems. If everything works fine I'll remove the old outline mode code and will look into doing some further optimizations. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

13 42

Buildtool fix
by Bob Jamison 03 Mar '07

03 Mar '07

Running buildtool today, there was an occasion where gcc stopped with an error, but there were only warnings on the output. Turns out that the code handling the piping of the messages from the shell was buggy. No wonder that people wanted a listing file. I don't have that file yet (soon), but the warnings and messages are -much- better now. Also, the latest MinGW mingw-runtime has gettimeofday() defined, while older versions do not. If you have a problem compiling buildtool with g++, try compiling with: g++ -O3 -DHAVE_GETTIMEOFDAY buildtool.cpp -o btool.exe I guess that later, when most people have the newer mingw, that can be changed to NEED_GETTIMEOFDAY for the Luddites. :-) bob

1 1

configure.ac for automake 1.10
by Pierre-Luc Auclair 03 Mar '07

03 Mar '07

Here's the file. Pierre-Luc

4 3

Fwd: git on win32
by David Douard 03 Mar '07

03 Mar '07

Sorry, I forgot to CC to mailing list ---------- Forwarded message ---------- From: David Douard <david.douard@...400...> Date: 27 févr. 2007 09:06 Subject: Re: [Inkscape-devel] git on win32 To: "Jon A. Cruz" <jon@...18...> Another solution might me to use Mercurial. It is very similar (in goals and day to day use) to git. It is written in Python. This is the tool we now use at Logilab for all of our projects (for a year now; we used to use CVS). Mercurial is incredibly fast (git also I guess). And once you have tasted disctributed SCM, well, you just can't imaging how you could have do without it for years... Seriously, give it a try. Note that the first impression might me disappointing, but once this step is done, what a pleasure... I used to be a big SVN fan (I still find SVN a noce tool, but...), but mercurial (ang git which really is very similar) is an incredible tool for every day work. This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform. http://www.selenic.com/mercurial/wiki/ Note also that there is "all-in-one" mercurial package for win32 . http://mercurial.berkwood.com/ David 2007/2/27, Jon A. Cruz <jon@...18...>: > > On Feb 26, 2007, at 1:58 PM, MenTaLguY wrote: > > > ...and however much of cygwin is necessary to make them all work. > > > -mental > > > Unfortunately I've found that cygwin makes many things significantly > slower. > > My other reservation would just be that git was made to solve certain > problems that we're not hitting on Inkscape. That point, though, is just > something I've not looked into. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

6 8

Last call for LGM brochure
by cedric GEMY 02 Mar '07

02 Mar '07

Hi guys We are soon ready to finish the brochure made for LGM. People who are interested can send me the nice artworks and design (in svg if possible) they have made, with credits+licence (use metadata for example). I can't promise it can be put within the brochure but there is a chance. Don't worry if you're not a professional : if you like your work may be others will like it too. For info : the brochure will be ditributed in 4000 ex with graphika which is a high level magazin for graphic designer in canada. The purpose of the brochure is to introduce and promote Inkscape (and others) to this public. Cedric (pygmee)

1 0

Re: [Inkscape-devel] [cairo] PS/PDF Gradients
by Carl Worth 02 Mar '07

02 Mar '07

On Mon, 29 Jan 2007 00:27:27 +1030, Adrian Johnson wrote: > I have been testing Miklós' PDF gradient patch from > http://lists.freedesktop.org/archives/cairo/2006-August/007648.html Thanks for keeping this alive, Adrian! I know that the inkscape developers, (among others), are very anxious to see cairo generate PDF files with native gradients rather than falling back to rasterization---since other than this issue, cairo is providing very good PDF export capability. > Looking at the patch the only obvious deficiency I could see is lack of > support for the different cairo_extend_t options. The patch has the PDF > /Extend value set to [true true] which is equivalent CAIRO_EXTEND_PAD. > > Testing linear gradients with rgb stops appears to be ok. Changing the > PDF /Extend value set to [false false] which is equivalent > CAIRO_EXTEND_NONE also works. OK, well one thing we definitely need is a test case for linear gradients with all of the extend modes, (could be much like the recent radial case I added). > The results of testing linear gradients with CAIRO_EXTEND_PAD and rgba > stops are: > acroread - ok but the colors seem to be too dark. > evince - broken, The padded region is opaque when it should have > some transparency. > ghostscript - broken. all opaque colors. no transparency. All I looked at was the output from poppler which the test suite uses. I'm also seeing the colors as too dark, but otherwise the results look quite promising, (again without testing extend modes yet). Here's the reference image (sorry it's so tiny): http://cairographics.org/~cworth/images/linear-gradient-ref.png and here's the rendering of the PDF output: http://cairographics.org/~cworth/images/linear-gradient-pdf-argb32-out.png So that just looks like one simple color scaling issue somewhere. And once we test the extend modes, it would at least be very easy to only turn on native gradients for known-good extend modes. > I have not tested radial gradients. I did now, and it's not too pretty. Here's our reference image: http://cairographics.org/~cworth/images/radial-gradient-ref.png and here's the rendering of the PDF output: http://cairographics.org/~cworth/images/radial-gradient-pdf-argb32-out.png So it looks like there's still a fair amount of work to be done there. Anyway, if anyone wants to help out with this, it would be *greatly* appreciated. I took this quick look to see if there was anything here in a state ready to make it into 1.4, but it looks like there's not. -Carl

2 2

NEW: Command line options
by Ted Gould 02 Mar '07

02 Mar '07

Hey, So I added in some new command line options that are fun. * --verb-list will list all the Verb IDs and their names in Inkscape. This makes writing your own menus and hotkeys much easier as you can easily find out what the choices are. * --verb followed by a verb ID allows you to specify a verb to be called on every document opened by Inkscape initially from the command line. * --select followed by a node ID will allow you to add a node to the list of selected objects. Now, initially I thought these would be really good for performance testing, and that was my driver. You could do something like this: $ time inkscape --verb=FileClose my_complex_file.svg And get a reasonable number. But, now, with the selection, I think it can be much more useful than that. You can call effects, or any other verb, then FileSave and FileClose to automate all kinds of things on your diagrams. Have fun, Ted

3 5

Re: [Inkscape-devel] Inkscape's user manual
by Cédric GEMY 02 Mar '07

02 Mar '07

To answer Bryce, i would be glad to merge efforts with other people. If those people who wants to contribute are mainly for a wiki solution, i'm ready to take if there is a possibility to transform it in more standard format. So my proposal/question would be : 1. make test on transforming wiki to docbook as mentionned 2. clear our mind on the subject 3. open a real space on inkscape.org for this 4. should work from scratch or on basis of mine or kevin's work ? 5. make some ToC to show where we should go 6. have our own release note in purpose to match as soon as possible inkscape releases (was until 0.44 for me in frech) 7. define internationalisation strategy and process My vision of the manual is not giving tutorials (inkscape has already that) but more something like a help file that give precise infos on functionnalities. Core Developers would be first interested in helping the manual or keep close to manual writers (with a reciprocity, of course ;) ) These functionnalities can be illustrate with examples or step by step description if needed. About tav's manual, it is evidently very good and i encourage it as any articles on inkscape (i write myslef some in magazins, soon one in Linux+DVD). But as discussed with Colin Marquee, it would be nice to have an inner help browserthat could be distributed in a different package (see gimp). Some words in the wiki about it. Hope it helps Cedric

1 0

Inkscape Project Status
by Bryce Harrington 02 Mar '07

02 Mar '07

Just to give some visibility into some of the work bubbling away these days: Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users. Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution. Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git. Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there? Manual: We've got a good unofficial non-free manual/book and several [semi-]official incomplete free manuals. There is discussion about if efforts can be combined to produce a good official free manual. Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up. Bryce

11 15

Re: [Inkscape-devel] Inkscape Project Status
by Colin Marquardt 01 Mar '07

01 Mar '07

"Leandro Regueiro" <leandro.regueiro@...400...> writes: > If you make a good manual I would translate it. I don't like the idea > of use SVG for docs. Please use another format. SVG can be converted to po with xml2po, so translators would have it as easy as with docbook. (I still like docbook for a task like a manual more.) Cheers Colin

1 0