Wed, 6 Jan 2010 00:39:56 +0300 Alexandre Prokoudine <alexandre.prokoudine@...400...> kirjoitti:
I think the most bang for the buck and most general would come from using 3D HW accel and moving to the extra memory provided by 64-bit.
You know it's amazing how much people trust in 3D acceleration and 64bit. I just hope we won't try to fix existing performance issues by neglecting them and going for 3D/64bit/whatever.
This talk about 64-bit confuses me... I've been using 64-bit Inkscape for years already, ever since I got my first 64-bit computer. (no significant performance boosts there, though I haven't done side-by-side comparision between 64-bit and 32-bit Inkscape)
As for rendering performance, I've been thinking about parallerizing the rendering. Rendering SVG can be thought as a graph. The nodes are rendering operations: draw this shape, draw this text, composite these images... and the edges are dependencies: before compositing, the to-be-composited images must be rendered, so there's an edge from each of those to the composite operation. This graph should be a DAG.
The main idea here is: some number of worker threads is spawned and whenever there is an idle worker thread and some ready-to-be-executed rendering operation, the operation is given to that thread. (ready-to-be-executed: all operations it depends on have been finished but the operation itself has not been started yet)
A small extra benefit also: if it happens that the graph is not a DAG, it could be detected. As it stands, Inkscape crashes in such situation. (see https://bugs.launchpad.net/inkscape/+bug/195320 )
I'd guess this would require massive changes to Inkscape renderer. As we're moving towards Cairo rendering, implementing this might not be that useful anyhow.