Re: [Inkscape-devel] Xara and Inkscape comparison on Linux ActionShow
On Thu, 25 Jan 2007 13:10:01 -0600, Aaron and Sarah Spike <spike@...749...> wrote:
The ability to draw those outlines will also be useful for blurred objects and objects that have live path effects applied. :-)
One thing we will need to be aware of, though, is that the render-only-the-displayed-portion-of-the-path optimizations apply only to NRArenaShape, not SPCanvasBPath (which is currently what we have to use for "annotations" like nodes and these hypothetical outlines). Kind of a shame since the two classes do essentially the same thing, and one of the reasons I think the canvas code needs to have the two layers unified somehow.
-mental
On Thu, Jan 25, 2007 at 11:34:12AM -0800, MenTaLguY wrote:
On Thu, 25 Jan 2007 13:10:01 -0600, Aaron and Sarah Spike <spike@...749...> wrote:
The ability to draw those outlines will also be useful for blurred objects and objects that have live path effects applied. :-)
One thing we will need to be aware of, though, is that the render-only-the-displayed-portion-of-the-path optimizations apply only to NRArenaShape, not SPCanvasBPath (which is currently what we have to use for "annotations" like nodes and these hypothetical outlines). Kind of a shame since the two classes do essentially the same thing, and one of the reasons I think the canvas code needs to have the two layers unified somehow.
Mental, would you mind explaining in detail how Inkscape handles this rendering? This has always been a foggy area for me, and even digging through the codebase it's not clear. However, I think it is key both for performance optimization and cairo adoption reasons that we all at least roughly understand the design of this aspect of Inkscape.
Bryce
On 1/25/07, MenTaLguY <mental@...3...> wrote:
One thing we will need to be aware of, though, is that the render-only-the-displayed-portion-of-the-path optimizations apply only to NRArenaShape, not SPCanvasBPath (which is currently what we have to use for "annotations" like nodes and these hypothetical outlines). Kind of a shame since the two classes do essentially the same thing, and one of the reasons I think the canvas code needs to have the two layers unified somehow.
Are you sure? This optimization was added by knutux into livarot's Path class, and SPCanvasBPath does use Path for rendering. So it either works now, or should not be too difficult to enable.
On Thu, 25 Jan 2007 16:20:49 -0400, "bulia byak" <buliabyak@...400...> wrote:
On 1/25/07, MenTaLguY <mental@...3...> wrote: Are you sure? This optimization was added by knutux into livarot's Path class, and SPCanvasBPath does use Path for rendering. So it either works now, or should not be too difficult to enable.
Sort of. As part of his work he added a two-argument form of Path::Convert which optimizes the piecewise-linear conversion for the supplied viewing region, but it's still up to the rest of the code to figure out what that region is and pass it to Convert at the appropriate time. He only added that additional logic to NRArenaShape, not SPCanvasBPath.
Perhaps the best thing to do at this point, instead of duplicating that logic in SPCanvasBPath, would be to switch to using an SPCanvasArena with a single NRArenaShape in the places where SPCanvasBPaths are used now, and get rid of SPCanvasBPath.
-mental
participants (3)
-
Bryce Harrington -
bulia byak -
MenTaLguY