Hi,
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately. Filter effects are recalculated for each tile that they touch. A typical canvas for maximized Inkscape window on a 1080p monitor is broken into about 25 tiles. If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
I've added a preference under the "Rendering" tab to change the relative tile size (Rendering tile multiplier). Please play with changing the value for your most complex drawings. I am most interested in cases where a large multiplier has a negative impact. If there are no cases with a negative impact, I'll set the default value higher (it is currently 1).
Tav
Am 30.03.2017 um 21:33 schrieb Tavmjong Bah:
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately.
I guess this is done to speed up rendering by panellizing the calculation? If this is true, couldn't we adjust the number of tiles relative to the number of CPU cores? (Maybe nCores * 2 or 3 in case some tiles are rendered faster than others)?
If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
Couldn't the result of the calculation be cached and re-used, i.e. calculate the filter once and then render all 25 tiles in parallel using the cached result?
One other question: Could the tiling somehow be related to https://bugs.launchpad.net/inkscape/+bug/1656383
Regards, Eduard
Bug 1656383 which Eduard links (horizontal stripe artifacts when zooming into a blur) is the same symptom which got significantly worse as I naively tinkered with the tile-size code last year. So I suspect Eduard's right that it's related.
On 31 March 2017 at 08:51, Eduard Braun <eduard.braun2@...173...> wrote:
Am 30.03.2017 um 21:33 schrieb Tavmjong Bah:
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately.
I guess this is done to speed up rendering by panellizing the calculation? If this is true, couldn't we adjust the number of tiles relative to the number of CPU cores? (Maybe nCores * 2 or 3 in case some tiles are rendered faster than others)?
If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
Couldn't the result of the calculation be cached and re-used, i.e. calculate the filter once and then render all 25 tiles in parallel using the cached result?
One other question: Could the tiling somehow be related to https://bugs.launchpad.net/inkscape/+bug/1656383
Regards, Eduard
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
On Thu, 2017-03-30 at 21:51 +0200, Eduard Braun wrote:
Am 30.03.2017 um 21:33 schrieb Tavmjong Bah:
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately.
I guess this is done to speed up rendering by panellizing the calculation? If this is true, couldn't we adjust the number of tiles relative to the number of CPU cores? (Maybe nCores * 2 or 3 in case some tiles are rendered faster than others)?
No. Actually the only parallelization we have is in the filter code. The tiling is done so that the part of the screen near the pointer is updated the fastest... which is most useful if you are editing a large drawing.
It would be interesting if we could paint multiple tiles at the same time but I have no idea how much work it would be to make that bit of the code thread safe.
If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
Couldn't the result of the calculation be cached and re-used, i.e. calculate the filter once and then render all 25 tiles in parallel using the cached result?
In principle yes. We do have some caching code but I don't know how it works.
One other question: Could the tiling somehow be related to https://bugs.launchpad.net/inkscape/+bug/1656383
Probably. In trunk, if you uncomment out line 322 in src/desktop.cpp (canvas_debug) the tiles will be shown in light red.
Tav
Regards, Eduard
This sounds amazing.
I spent some time about eight months ago trying to figure out the primary bottleneck with the rather slow gaussian blur filter, thinking it just needed some box-blur optimisations link described in http://blog.ivank.net/fastest-gaussian-blur.html. But turns out the IIR version already takes care of performance at that level.
At which point I noticed that the blur filter was being called multiple times (and more as I increased zoom level) on what I thought should be a single pass. At that point, the code got a bit beyond what I had time to figure out, but I believe I was running into the tile rendering Tav describes. My naive attempts at eliminating it just made everything look awful, so I gave up.
Anyway, what I did learn was (from memory): the blur algorithm itself is *fast*, at least on my (not particularly spectacular) machine. There's nothing particularly wrong with it, and while any optimisations with it might help, the real problem is that it's being run so many times. The same algorithm, run a single time on my 1080p screen, would feel snappy.
So I'm excited to see some experimenting done on this score, and I'd love it if that tile-size setting could remain available. I'm keen to test it, but I don't think I'll get a chance to build the source in the near future.
Will I be able to try this in a nightly build from somewhere (Ubuntu/Elementary OS)?
Thanks, Tav.
- Bryan
On 31 March 2017 at 08:33, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately. Filter effects are recalculated for each tile that they touch. A typical canvas for maximized Inkscape window on a 1080p monitor is broken into about 25 tiles. If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
I've added a preference under the "Rendering" tab to change the relative tile size (Rendering tile multiplier). Please play with changing the value for your most complex drawings. I am most interested in cases where a large multiplier has a negative impact. If there are no cases with a negative impact, I'll set the default value higher (it is currently 1).
Tav
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
The change in preferences has not hit the inkscape-trunk ppa yet. When it does, I'll test and report back. Thanks for looking into this, Tav!
-C
On Thu, Mar 30, 2017 at 8:33 PM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately. Filter effects are recalculated for each tile that they touch. A typical canvas for maximized Inkscape window on a 1080p monitor is broken into about 25 tiles. If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
I've added a preference under the "Rendering" tab to change the relative tile size (Rendering tile multiplier). Please play with changing the value for your most complex drawings. I am most interested in cases where a large multiplier has a negative impact. If there are no cases with a negative impact, I'll set the default value higher (it is currently 1).
Tav
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
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.
Vlada
On Thu, Mar 30, 2017 at 9:33 PM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
It's been known for a while that rendering when zooming in on an area with filters is slow. This is due to Inkscape breaking the canvas into tiles and rendering each tile separately. Filter effects are recalculated for each tile that they touch. A typical canvas for maximized Inkscape window on a 1080p monitor is broken into about 25 tiles. If you are zoomed in so that the filter extends over the entire visible canvas, you are recalculating the filter effect 25 times.
I've added a preference under the "Rendering" tab to change the relative tile size (Rendering tile multiplier). Please play with changing the value for your most complex drawings. I am most interested in cases where a large multiplier has a negative impact. If there are no cases with a negative impact, I'll set the default value higher (it is currently 1).
Tav
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
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
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.
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.
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.
Hope it helps! -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
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
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
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
While I was thinking about 3D rendering engine, and game engine. I think that priorization should be a thing for different areas of a svg file. The greater the amount of datas or details found in an area, then the higher priority the rendering engine goes. The idea is for the render engine to focus on the more complicated area, and quickly generate the simpler area. What are your thoughts?
On 4/3/2017 6:05 AM, Yale Zhang wrote:
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
participants (7)
-
Bryan Hoyt -
C R -
Eduard Braun -
Miguel Lopez -
Tavmjong Bah -
Vladimir Savic -
Yale Zhang