Mr. Solaris Manzur I have to agree with that - but Inkscape developers and another 1.456.742 + 1/2 peoples know about that too.

To reach Xara renderer (or ar least CorelDraw) speed is still a long way for Cairo - even we all dream to that day.

I'm afraid at this point Inkscape development follow some other specific tasks (check the roadmap to know more), when the right time will come Inkscape renderer will see all requested optimizations.

One thing must be clear at least to you now- we all know about that, users and developers.

We all hope in better ;)

2009/8/9 Preben Soeberg <prsodk@...400...>:

...

-----Original Message----- From: Diederik van Lierop [mailto:mail@...1689...] Sent: 09 August, 2009 15:04 To: solaris manzur Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] inkscape is getting good but heavy and slow

On 08/08/2009 05:42 PM, solaris manzur wrote:

...

hello folks, inkscape is getting slower more and more, the same in windows, please be carefull with this, i do not want to have another windows vista case, please play attention to my word, i just want free software to be the best around the world thanks for listening

Could you be more specific? Under what circumstances is Inkscape getting slow? On complex documents? On startup? On rendering of filters? Which versions are you comparing? Can you measure it?

Diederik

One problem I can point at, is that mouse queue message handling takes a lot of time. Having a design with a few thousand nodes and leaving the puck on the tablet can easily use 100% CPU without getting any real work done.

I have a feeling, that this message queue handling has gone slower lately, but I can not point at a time it happened.

Wacom message rate limiting is almost a must, and as a side note it should also be forbidden to give the same coordinate pairs twice in sequence (see https://bugs.launchpad.net/inkscape/+bug/284546).

So, I also send this comment to Tor Lillquist, in the hope something can be worked out on the gtk+ side.

Preben

...

---

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30- Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Preben Soeberg wrote:

One problem I can point at, is that mouse queue message handling takes a lot of time. Having a design with a few thousand nodes and leaving the puck on the tablet can easily use 100% CPU without getting any real work done.

I am not familiar with the renderer, but perhaps this could be sped up a lot by: 1. rate limiting GDK_MOTION_NOTIFY in emit_event (it's in sp-canvas.cpp if anyone wants to have a look). 2. Maintaining a 2D interval tree of object bboxes in SPDocument, so that sp_event_context_find_item, as well as the code that finds the item to emit the events on, is faster. 3. Optimize the nearestPoint routine (for example my node tool needs to call this on every motion event).

In any case, any slowness people might experience is not a result of bloat, but of a lack of optimizations or using suboptimal data structures (for example we are using a singly-linked list for selection contents, where we should be using a multi-indexed container with a list and a hash index, preferably via Boost.Multiindex). Therefore we are on the opposite end with regards to the Vista case :)

My 2 cents in the performance discussion: we should attempt to improve the startup time, as this is the most apparent metric of a "bloaty" feel. I wasn't able to identify any big bottlenecks with gprof, but adding some print statements with timing information at critical places might turn up something.

Regards, Krzysztof