I'm back from vacation and gave this a try. I use blurs and turbulence all the time, so I definitely see a huge improvement. Thanks. I see this as an example of trading low latency for higher throughput.
But increasing the block size doesn't solve the fundamental problem of redundant rendering (the amount of redraw is even worse when filters use the background image). I've been working on multithreaded rendering (not just for filters) and have a working prototype with ~2.4x speedup using 8 threads. I simply divide each dirty rectangle to redraw into 8 horizontal stripes for OpenMP to split the work. I don't know if the redraw is what's limiting the speedup for my drawing, but it's clear even for 4 threads/blocks, redraw can still be a big problem. So to make parallel rendering effective, redraw will have to be eliminated.
How to do it has been troubling me for months. A simple way could be to render the entire visible object instead of just the part inside the current block. Then when rendering another block, the object will hopefully be in the cache. This should be fine for 1 thread, but for multiple threads, the load imbalance could be terrible.
But this should be good enough. Multithreaded rendering doesn't have to be faster in these pathological cases. It just shouldn't be any slower than single thread.
Another thing I'd like to try is instead of dividing the screen into blocks for each thread to render, just render the whole screen as 1 block, but render the objects in parallel. I don't know if GNU's OpenMP will ||ize || regions nested inside other || regions > 2 levels deep.
On Sat, Apr 1, 2017 at 5:05 PM, Miguel Lopez <reptillia39@...3425...> wrote:
So, I have been testing this new feature, and I have to say that there's improvement on rendering results as well. In fact, some artifacts I have noticed with guassian blur are completely gone with the value of rendering tile multiplier. My sample file was the shoe I was working on which is a 5+ MB SVG File with multiple blend, and guassian blur factor. A lot of the bugs with blur can be safely considered as resolved in my opinion, but that needs testing.
On 4/1/2017 3:17 AM, Tavmjong Bah wrote:
On Fri, 2017-03-31 at 23:33 +0100, C R wrote:
Okay, so yes, for me increasing the rendering tile multiplier value from the default of 1 up through about 10 turns several seconds of redraw time into instantaneous. I work in Inkscape on a laptop with 4 cores, but values greater than 4 still have a significant impact on the speed.
The multiplier does not change the number of cores used. Rather, it increases the area Inkscape renders in one go. This reduces the number of times it has to recalculate filter effects.
I used a file with a single object containing 94000 nodes in it, blurred and zoomed to %3178.
Results:
1 = 4 second redraw 2 = 2 second redraw 3 = 1 second redraw 4 = .75 second redraw 5 = .5 second redraw 6 = .25 second redraw 7+ = no visible delay unless moving
It's a bit hard to tell the redraw speed while moving the view because Cairo seems to mess the preview at this zoom level if you are moving the view.
This won't change the redraw speed when moving the view as the new area(s) will be rendered separately.
Another effect of increasing this multiplier is that you can now zoom in to a point where Inkscape core dumps (segmentation fault). Wereas before, you were just stuck waiting endlessly for your canvas to redraw. Neither is great, and there should probably be something in place to keep the user from zooming past what their machine hardware can handle safely.
Ooh, cool! OK, not so cool. But having a core dump will show where in the code the problem is... however, I could not get it to produce a segmentation fault in gdb but could outside so it will take a bit of work.
Hope it helps!
Certainly does!
Thanks,
Tav
-C
On Fri, Mar 31, 2017 at 9:06 AM, Tavmjong Bah <tavmjong@...8...> wrote:
On Thu, 2017-03-30 at 23:55 +0200, Vladimir Savic wrote:
Hi Tav and others!
Thanks for your hard work. I appreciate it really. Looking forward to other improvements.
Can you please try Yale`s patch for multithreaded rendering we talked on this list already. I think it is possible to find it in some meiling list thread, but in case you can`t, I`ll find it myself tomorow when I come to my desktop computer. It does wonders on this i7 6700 processor.
I do want to look at this but won't have time till the end of April. Keep after me if it doesn't get merged.
Tav
Vlada
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel