I recently made a grid in Inkscape and tried to apply the Perspective LPE. It was a nightmare.
Was lagging big time to a point where it was impossible to do any more work on the project.

Then i imported the svg file into Gimp and everthing worked like a breeze.
No lagging, you could move the huge number of nodes around with no problem.

Why is that ?
Is Inkscape crippling its performance by design ?

It's the LPE, I would guess. It's creating the effect from the original path, but also simultaneously writes a copy of the result of the operation and its current settings into the SVG.

What you did in Gimp was using the result, in Inkscape you worked on the original path, with the result being continuously created in real time.

Moini wrote:It's the LPE, I would guess. It's creating the effect from the original path, but also simultaneously writes a copy of the result of the operation and its current settings into the SVG.

What you did in Gimp was using the result, in Inkscape you worked on the original path, with the result being continuously created in real time.

You misunderstand me.
Here is a 800x800px grid i made by combining 2px strokes. It has 120 nodes.
Applying the Perspective/Envelope LPE works okay.

Now when i convert the strokes to paths and unify everything, node count rise to 3600.
Applying the LPE gets Inkscape to its knees.

Now loading the same 3600 node grid into Gimp and using the Perspective Tool in Path-mode works pretty smoothly.
It lags a bit, but its not crippling.

Yes, you're right. I didn't even know that the Gimp perspective tool *has* a path mode I understood that you only move the nodes in Gimp, and apply the effect in Inkscape and move it around. So the gimp tool works on vector objects, too?

Still I think the cause is valid (aside from performance not being optimal in Inkscape, which is true). Does gimp apply the effect dynamically, or do you use it once, and then continue to edit the manipulated nodes?

It seems you must be using an Inkscape prerelease version, because the stable one doesn't have a perspective LPE, only an envelope deformation LPE.
If you use 0.92pre with perspective LPE, and enter the corner nodes' values in the form, performance is okay, unless you start to edit grid nodes, or move the corner nodes on canvas. Then it drops dramatically, because the LPE is always applied on top, and it seems to calculate intermediate steps which aren't needed.

Moini wrote:Yes, you're right. I didn't even know that the Gimp perspective tool *has* a path mode I understood that you only move the nodes in Gimp, and apply the effect in Inkscape and move it around. So the gimp tool works on vector objects, too?

Still I think the cause is valid (aside from performance not being optimal in Inkscape, which is true). Does gimp apply the effect dynamically, or do you use it once, and then continue to edit the manipulated nodes ?

Yes, Gimp has the capability to work with paths.
Most tools have a raster, a selection and a path mode.

So rotation, scaling, moving, perspective, etc.
Transforming paths, thats all possible with Gimp.
And with optional plug-ins, even more functionality is possible (text on a path, interpolation, etc.)

You can modify the paths as many times as you want. At least when it comes to perspective. Although you cant go back to the exact original state once its transformed. But making a copy of the original path does not seem to be a big deal (and Illustrator cant go back as well, once you expand an effect).

My point is that a lot of the Gimp path tools seem to perform better than its Inkscape counterparts and this seems like an odd weakness for a program that specializes in vector graphics.

What is unfortunate about Inkscape is that a lot of the functionality seems great in theory but once you apply it to a real project, many problems arise.

Moini wrote:It seems you must be using an Inkscape prerelease version, because the stable one doesn't have a perspective LPE, only an envelope deformation LPE.

Yes i was using a 0.92pre release.

Moini wrote:If you use 0.92pre with perspective LPE, and enter the corner nodes' values in the form, performance is okay, unless you start to edit grid nodes, or move the corner nodes on canvas. Then it drops dramatically, because the LPE is always applied on top, and it seems to calculate intermediate steps which aren't needed.

Well if live performance doesnt work very well, why does Inkscape not go the Illustrator way and work with a matrix ?
You type in values, hit enter and the transformation is applied. Seems safer than a lagging live effect, that is hardly usable.

I assume that's because it works quite well with smaller objects, and it's quite comfortable for those, as it lets you look at the result right away, and also allows to edit the original object.
I've mostly seen people use this kind of functionality (the envelope extension - that's what comes closest in 0.91) to deform text, not so much a huge array of nodes like your grid (maybe an extension that generates a grid in perspective would be more helpful? It might already exist... although it seems you're after deforming the grid line width, too, so probably that wouldn't help, right?).

The option to enter corner coordinates exists, too. It's not a matrix, so it's probably even easier to use for the non-mathematically inclined users. As for the matrix entering, you can use the 'Transform' dialog in the Object menu. LPEs are for when it's important that you preserve the ability of editing the original object. There's also a perspective extension, if that ability is not important for you.

Do you maybe happen to know someone who's into performance optimization, and can program in C++? Non-programming help is also welcome, as it takes some load off the developers, so they can focus on their main skills.

Moini wrote:I assume that's because it works quite well with smaller objects, and it's quite comfortable for those, as it lets you look at the result right away, and also allows to edit the original object.
I've mostly seen people use this kind of functionality (the envelope extension - that's what comes closest in 0.91) to deform text, not so much a huge array of nodes like your grid

Right. Thats not obvious, though.

It might already exist... although it seems you're after deforming the grid line width, too, so probably that wouldn't help, right?).

Yes, i was trying to get a perspective effect on a grid and the Perspective LPE seemed like the best tool.
But thats just an example for a project (as good as any one) im trying to realize. And not overly complicated you might think.

Do you maybe happen to know someone who's into performance optimization, and can program in C++? Non-programming help is also welcome, as it takes some load off the developers, so they can focus on their main skills.

I have no knowledge in this field.
There are some people in the Gimp world who can write python plug-ins for paths. But only a handful at best.
Never heard of anybody who had C++ skills.

As it was quite late last night, I forgot to mention the most obvious solution (thought of it only after switching off...):
remove the path effect, by doing Path -> Object to path, after you have applied the LPE and the perspective looks right.

It's also my experience that Inkscape can better deal with many small objects than with one large object.
Then there's the extension, of course.

Did any of these hints help in any way to move you forward towards your goal?

I already achieved my goal...i used Gimp instead of Inkscape.
My main concern wasnt the project, its the question why Inkscape has such bad performance issues.

Yes, you offered a few alternatives how to handle the lagging of the LPE.
It makes me wonder why i have to start a new topic, everytime i try to do something quite basic.

Same here:
viewtopic.php?f=22&t=31371&p=94440

The basic 'why' is, as always, 'because someone made it in this way and nobody changed it'.

There is probably no deeper explanation than that, for any of the 'why is there a bug', 'why is performance like this', 'why isn't this bug fixed already', 'why does it work like this and not like that' questions.

The resources the Inkscape project has for doing any kind of work - be it development, user support, website contents, organizing events, building infrastructure or anything else - are limited, especially by the number of persons who are able to and voluntarily do help with taking the project forward.

There are many, many things that would need some loving attention, and there are many, many users who happily use Inkscape. But only few of them want to invest the courage / time / (effort to learn) abilities it takes to work in, with and for the community. Not even one person volunteered to help write an announcement. Not one person out of the millions of people out there who use Inkscape seems to be able to package for OS X.

So the questions people should ask are either:
- How can I help to make this functionality work better?
- or, for all those who cannot/don't want to contribute, and to bridge the time until something is fixed: Is there a workaround that enables me to live with the situation, without improving anything really.