« Return to Thread: Re: [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
Re: [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
by Vangelis Katsikaros-2
::
Rate this Message:
Jasper van de Gronde wrote:
> And please be sure to file a bug/feature request at
> http://bugs.launchpad.net/inkscape/
>
> In the end there will obviously always be cases where Inkscape is too
> slow, but Inkscape could most definitely be faster in some cases. And
> just locking/unlocking the layer should (from an intuitive standpoint)
> NOT cause such a big pause.
>
> Dave M G wrote:
>> Donn,
>>
>> Thank you for responding.
>>
>>> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs
>>> of RAM. It makes no difference. I think it's all the looping through those long
>>> lists of nodes....
>>>
>>> You are doomed. Unless you can simplify or chop-up your comic page into frames
>>> and assemble them later in Gimp.
>> Okay. While it's a little disappointing that there isn't a way to
>> optimize the file for better performance, it's good to know that at
>> least I'm not doing something wrong.
>>
>> I'll export the paths into a PNG and handle the colouring in Photoshop
>> or GIMP. It means committing to rasterizing the images sooner in my
>> process than I had hoped, but hey, life is full of compromises.
>>Hello!
My name is Vangelis Katsikaros. I have worked a bit with Nathan Hurst
(he was kind enough to provide feedback and guidance) in lib2geom on the
direction of making Inkscape more efficient when a lot of "shapes" are
in a file.
Currently Inkscape looks *all* the shapes in order to find which are in
the user's window (correct me if I am wrong). This is actually a spatial
2D query and has been solved efficiently in GIS database systems. Now,
lib2geom offers a simple R-Tree solution, allowing for 2D spatial
querying. There are still a couple of small tasks to do, and then we
should go from memory-only indexing to memory-and-disk indexing (so the
project isn't complete yet :)
After we have an efficient way to find what must be rendered, the 2nd
issue is rendering more efficiently. Nathan suggested that mipmaps
could be incorporated in the R-Tree thus allowing to pre-render small
shapes (related to the user's window).
I still have more work to do (to finish the rtree) and then are many
paths to follow. Any comments or thoughts would be interesting :)
Regards
Vangelis Katsikaros
__________________________________________________
×ñçóéìïðïéåßôå Yahoo!;
ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí
http://mail.yahoo.gr
------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> And please be sure to file a bug/feature request at
> http://bugs.launchpad.net/inkscape/
>
> In the end there will obviously always be cases where Inkscape is too
> slow, but Inkscape could most definitely be faster in some cases. And
> just locking/unlocking the layer should (from an intuitive standpoint)
> NOT cause such a big pause.
>
> Dave M G wrote:
>> Donn,
>>
>> Thank you for responding.
>>
>>> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs
>>> of RAM. It makes no difference. I think it's all the looping through those long
>>> lists of nodes....
>>>
>>> You are doomed. Unless you can simplify or chop-up your comic page into frames
>>> and assemble them later in Gimp.
>> Okay. While it's a little disappointing that there isn't a way to
>> optimize the file for better performance, it's good to know that at
>> least I'm not doing something wrong.
>>
>> I'll export the paths into a PNG and handle the colouring in Photoshop
>> or GIMP. It means committing to rasterizing the images sooner in my
>> process than I had hoped, but hey, life is full of compromises.
>>
My name is Vangelis Katsikaros. I have worked a bit with Nathan Hurst
(he was kind enough to provide feedback and guidance) in lib2geom on the
direction of making Inkscape more efficient when a lot of "shapes" are
in a file.
Currently Inkscape looks *all* the shapes in order to find which are in
the user's window (correct me if I am wrong). This is actually a spatial
2D query and has been solved efficiently in GIS database systems. Now,
lib2geom offers a simple R-Tree solution, allowing for 2D spatial
querying. There are still a couple of small tasks to do, and then we
should go from memory-only indexing to memory-and-disk indexing (so the
project isn't complete yet :)
After we have an efficient way to find what must be rendered, the 2nd
issue is rendering more efficiently. Nathan suggested that mipmaps
could be incorporated in the R-Tree thus allowing to pre-render small
shapes (related to the user's window).
I still have more work to do (to finish the rtree) and then are many
paths to follow. Any comments or thoughts would be interesting :)
Regards
Vangelis Katsikaros
__________________________________________________
×ñçóéìïðïéåßôå Yahoo!;
ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí
http://mail.yahoo.gr
------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
« Return to Thread: Re: [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
| Free embeddable forum powered by Nabble | Forum Help |
