The maps I make have been growing increasingly intricate, and while Inkscape can still edit them, the performance has grown awfully slow. Even a simple act like copying and pasting a two-vertex curve with an arrowhead can take 3-5 seconds.
It seems like the bottleneck is that Inkscape runs everything through the CPU instead of the GPU. I open the same SVG files in Affinity (which implements NV path rendering, though it lacks other features) and the performance issues disappear.
Is a conversion to NV path even on the radar right now?
Others might know the answer to your question. I'll be curious to learn more. But for myself, what is "NV path" ?
My current understanding is that RAM is usually the limiting factor for performance issues. (It's what I've been told in the past, not from any technical understanding of my own.) Although I understand that filters and other raster content uses the cpu more. There are some settings to help with filter use, if your files use filters.
I'm familiar with those techniques. When I work with filters I do sometimes run into even worse performance, but often I see issues even without filters. And based on data from Task Manager on Windows, it's definitely the CPU that's the bottleneck, not the RAM (and this is on a very new work laptop).
As for nv_path_rendering, it's an extension to OpenGL designed to render SVG and other two-dimensional curve-based graphics with higher performance than what is provided by a typical CPU.
Some background...
Processing and editing graphics requires LOTS of math, especially floating point arithmetic. Programs that use 3D graphics tend to call functions in either DirectX or OpenGL to render scenes in three dimensions, and the major GPU manufacturers (AMD, Nvidia, & Intel) provide drivers that implement OpenGL and DirectX functionality. When your OS sees one of these functions come up in an application that uses 3D graphics, it's configured to hand that function off to the graphics driver. That driver, in turn, hands most of the calculations off to the GPU instead of making the CPU do all that work. GPUs are optimized for floating-point arithmetic calculations and can do them far faster and more accurately than the CPU.
SVG rendering also requires lots of floating point math; however, there are major difference between typical 3D rendering and SVG-style rendering. For years, this meant that performance increases in GPU hardware and drivers wouldn't provide better rendering for SVG, fonts, and other 2D graphics that use continuous curves. However, back in 2012, Nvidia presented research at the SIGGRAPH academic conference whereby they'd invented and implemented algorithms that would bridge that gap. They call it NV Path Rendering, and it's a low-level code library that, when invoked by an application, can shift the work of mathematical calculations for SVG rendering to the GPU instead of leaving it solely for the CPU.
What this means practically
NV Path Rendering is the sort of low-level code library that the typical end user doesn't have to care about. It's already running in Chrome and Firefox (via Skia), for example. It's also being used by Adobe Illustrator and Affinity Designer, both of which perform considerably better than Inkscape. It currently means that people who work in complex SVG have three bad options for editors: expensive (Adobe), incomplete (Affinity), or slow (Inkscape).
The blocker I believe is Cairo. Which is pratically abandonware for all the activity going on. Once we've got 1.0 out the way, we're going to need a special recruitment project to put together an alternate rendering project.
@NoPunIn10Did If you are interested in being a part of a recruitment project, or to work on the project iself. We could put together mentoring to get it off the ground and make sure we can find the people/resources needed to start it.
I'm not sure how much help I'd be in terms of actual coding, as it's been years since I've worked in graphics library code (OpenGL at the time). But I'd definitely be interested in helping in whatever way I have the bandwidth and knowledge for.
@NoPunIn10Did You can come join us on chat.inkscape.org the developer channel. It's a good starting point to chat about what we should do next on the topic. Code is only one small part of the project, getting the political will and managing the thing is also a job worth doing.
Beyond the Basics Where is NV Path Rendering on the priority list?
Inkscape.org
The maps I make have been growing increasingly intricate, and while Inkscape can still edit them, the performance has grown awfully slow. Even a simple act like copying and pasting a two-vertex curve with an arrowhead can take 3-5 seconds.
It seems like the bottleneck is that Inkscape runs everything through the CPU instead of the GPU. I open the same SVG files in Affinity (which implements NV path rendering, though it lacks other features) and the performance issues disappear.
Is a conversion to NV path even on the radar right now?
Others might know the answer to your question. I'll be curious to learn more. But for myself, what is "NV path" ?
My current understanding is that RAM is usually the limiting factor for performance issues. (It's what I've been told in the past, not from any technical understanding of my own.) Although I understand that filters and other raster content uses the cpu more. There are some settings to help with filter use, if your files use filters.
If you aren't already aware of them, this tutorial cover some techniques that can help you keep working in a heavy file: https://forum.inkscapecommunity.com/index.php?action=articles;sa=view;article=35
I'm familiar with those techniques. When I work with filters I do sometimes run into even worse performance, but often I see issues even without filters. And based on data from Task Manager on Windows, it's definitely the CPU that's the bottleneck, not the RAM (and this is on a very new work laptop).
As for nv_path_rendering, it's an extension to OpenGL designed to render SVG and other two-dimensional curve-based graphics with higher performance than what is provided by a typical CPU.
Some background...
Processing and editing graphics requires LOTS of math, especially floating point arithmetic. Programs that use 3D graphics tend to call functions in either DirectX or OpenGL to render scenes in three dimensions, and the major GPU manufacturers (AMD, Nvidia, & Intel) provide drivers that implement OpenGL and DirectX functionality. When your OS sees one of these functions come up in an application that uses 3D graphics, it's configured to hand that function off to the graphics driver. That driver, in turn, hands most of the calculations off to the GPU instead of making the CPU do all that work. GPUs are optimized for floating-point arithmetic calculations and can do them far faster and more accurately than the CPU.
SVG rendering also requires lots of floating point math; however, there are major difference between typical 3D rendering and SVG-style rendering. For years, this meant that performance increases in GPU hardware and drivers wouldn't provide better rendering for SVG, fonts, and other 2D graphics that use continuous curves. However, back in 2012, Nvidia presented research at the SIGGRAPH academic conference whereby they'd invented and implemented algorithms that would bridge that gap. They call it NV Path Rendering, and it's a low-level code library that, when invoked by an application, can shift the work of mathematical calculations for SVG rendering to the GPU instead of leaving it solely for the CPU.
What this means practically
NV Path Rendering is the sort of low-level code library that the typical end user doesn't have to care about. It's already running in Chrome and Firefox (via Skia), for example. It's also being used by Adobe Illustrator and Affinity Designer, both of which perform considerably better than Inkscape. It currently means that people who work in complex SVG have three bad options for editors: expensive (Adobe), incomplete (Affinity), or slow (Inkscape).
I've heard people wish for using the GPU for rendering and developers agreeing that it would be nice, but no one is actively working on it.
(@brynn : Alex is right about the RAM / CPU thing)
The blocker I believe is Cairo. Which is pratically abandonware for all the activity going on. Once we've got 1.0 out the way, we're going to need a special recruitment project to put together an alternate rendering project.
@NoPunIn10Did If you are interested in being a part of a recruitment project, or to work on the project iself. We could put together mentoring to get it off the ground and make sure we can find the people/resources needed to start it.
@doctormo
I'm not sure how much help I'd be in terms of actual coding, as it's been years since I've worked in graphics library code (OpenGL at the time). But I'd definitely be interested in helping in whatever way I have the bandwidth and knowledge for.
@NoPunIn10Did You can come join us on chat.inkscape.org the developer channel. It's a good starting point to chat about what we should do next on the topic. Code is only one small part of the project, getting the political will and managing the thing is also a job worth doing.