LPEs are slower to move than normal paths

[Pablo Trabajos]

When moving, some LPEs seems to take more work to render than even a copy of themselves converted to a path.

Steps to reproduce:
1-Draw an object
2-Apply an LPE
3-Make a copy and convert it to a path
4-Compare

I will post more information on this. I need to know if it happens with every LPE.

[Joshua Blocher (verbalshadow)]

Assigning to Johan for his review.

[Joshua Blocher (verbalshadow)]

I see a range of slow down moderate to temporary freezing.

[Johan Engelen (johanengelen)]

What exactly is the problem?
A path with LPE will be slower than when the result is converted to path.
So making a copy and converting it to normal path should be quicker.

[Joshua Blocher (verbalshadow)]

I believe the issue is that the LPE shouldn't have to completely recalculate everything to just move an already created path.
This maybe a premature optimization, but if it process could "short circuit" it could be almost as fast.

[Pablo Trabajos (pajarico)]

>I believe the issue is that the LPE shouldn't have to completely recalculate everything to just move an already created path.
Exactly. It seems a LPE it gets some more calculation than the same LPE converted to a path even when just moving.

Johan:
>A path with LPE will be slower than when the result is converted to path.
Yes, that's exactly the problem. Is there any reason?

>So making a copy and converting it to normal path should be quicker.
Then part of the point of using LPEs gets lost. The strength is to be able to edit them on the place, not to have to copy it every time i want to make a change.

[Johan Engelen (johanengelen)]

When you apply an LPE to a path, the LPE is recalculated whenever the original path data changes.
So when you move or scale a path with LPE, the original path data is moved or scaled. This triggers recalculation of the LPE.

It is possible to optimize moving a path with LPE. But I'd rather spend my time on things that I find more important right now.
(Moving the path by click-dragging with the mouse only recalculates the path when the mousebutton is released. The slowness during that dragging is caused by slow rendering, not by the slow LPE.)

[Pablo Trabajos (pajarico)]

> When you apply an LPE to a path, the LPE is recalculated whenever the original path data changes.
> So when you move or scale a path with LPE, the original path data is moved or scaled. This triggers recalculation of the LPE.
That sounds logical, except that path data is not changed when moving (at least it shouldn't trigger a LPE recalculation). I'm not programmer and don't know how Inkscape internals work so maybe is impossible/hard to do, I'm basing myself on a guessing.

>It is possible to optimize moving a path with LPE. But I'd rather spend my time on things that I find more important right now.
Then could we keep this open as a low priority wish or something?

[Maximilian Albert (cilix)]

As far as I can tell, it shouldn't be hard to make mere moves/scalings not trigger a recalculation of the LPE. I think there is even a flag indicating such changes in the SPObject model. I'd like to see that implemented, too (although, as Johan pointed out, it doesn't seem to be the major cause of the slowdown). However, depending on the LPE, simply moving/scaling the original path might *not* result in the recalculated path having the same translation/scaling applied because a LPE can turn the path into anything. I believe for all existing LPEs this wouldn't be an issue but you never know what people wil come up with in the future. Just to keep it in mind.

[Maximilian Albert (cilix)]

@Johan: If the rendering is the main cause of slowdown, why is the rendering slower with LPE applied than without?

[Jabiertxof (jabiertxof)]

New implemetations dont penalize translating LPE, is a bit slower on click release but is normal because need a extra calculation than a normal path.

I mark as fixed, please feel free to reopen if anybody find a big slownes while draging.

[Jabiertxof (jabiertxof)]

Forget myprevious input 0.92.x recalculate on move and is fixed in 0.92.x r.f15be3fc