I'm kinda confused, that rendering takes a lot longer, when I zoomed in to a place, while when zoomed out moving objects was quite fast, but well, is not a accurate of course. Any explanation for the really annoying slow down when zoomed in?
David
I'm kinda confused, that rendering takes a lot longer, when I zoomed in to a place, while when zoomed out moving objects was quite fast, but well, is not a accurate of course. Any explanation for the really annoying slow down when zoomed in?
It was discussed in this list before, I think. Look up the archives.
Anyway, has the slowness you're talking about became worse recently, or is it the same as before? Right now we're only interested in recent regressions to fix for the release.
On Thu, 2004-11-18 at 17:02, David Christian Berg wrote:
I'm kinda confused, that rendering takes a lot longer, when I zoomed in to a place, while when zoomed out moving objects was quite fast, but well, is not a accurate of course. Any explanation for the really annoying slow down when zoomed in?
livarot, like most renderers, approximates bezier curves by subdividing them into shorter line segments. As you zoom, livarot divides them more finely, creating more line segments.
On top of this livarot finds the intersection of all of the subdivided segments with each other, divides them again at their intersection points, and re-winds the path. For rendering, I don't think this is actually necessary.
The resulting polygon is cached, but needs to be recomputed every time the "original" path is changed.
Also, any operations with it still take a long time because their are so many line segments after fine subdivision -- including mouse motions, which currently check to see which shape they are inside for each mouse event.
Approaches to remediation include:
* only compute the subdivided/stroked/etc paths for the portions that are within the viewport or dirty area (tricky for dashed strokes though)
* remove the unneeded self-intersection (fred tells me it was a workaround for a bug that he never understood)
* only repaint the section of the path that changed
* stop routing events through NRArenaItems, at least for SVG objects
Probably all of these are too agressive to attempt for this release, unfortunately.
-mental
I'm not sure if it has become worse, Bulia, I just noticed it to be really, rally slow. Maybe that is due to the document I'm working with. I mean if your right about livarot, Mental, and I guess you are, it makes a lot of sense to me, that it's becoming slow, since I have a large text as curves in that doc and this means livarot will divide all the letters into tiny segments. I believe that just rendering the viewport or the viewport plus a border to allow rather fast movement on the canvas (is that the "dirty area"?) will speed up rendering a lot. Anyways, I know that there was a thread about this, but I obviously remembered the facts wrong because I thought it _was_ only rendered in the viewport. That is what really confused me, so sorry for bringing it up again. I don't care about it being in the release. I mean, it'll just postpone the release, and I can just as well build inkscape from cvs once it's in.
David
On Fri, 19 Nov 2004, David Christian Berg wrote:
Anyways, I know that there was a thread about this, but I obviously remembered the facts wrong because I thought it _was_ only rendered in the viewport.
Actual rasterization only happens in the viewport. However, it's still necessary to account for portions of the shape outside the viewport somehow (particularly for filling).
Our problem is that we currently do far more computation than is necessary for those "outside" portions of the path, and livarot's inefficiencies magnify that effect.
-mental
participants (3)
-
bulia byak -
David Christian Berg -
MenTaLguY