Canvas tile size and rendering speed.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Canvas tile size and rendering speed.

Tavmjong Bah

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Eduard Braun
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Bryan Hoyt | Brush Technology
In reply to this post by Tavmjong Bah
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



--
Bryan Hoyt, Software Developer  --  Brush Technology
Ph: +64 3 741 1204     Mobile: +64 21 238 7955
Web: brush.co.nz

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Bryan Hoyt | Brush Technology
In reply to this post by Eduard Braun
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



--
Bryan Hoyt, Software Developer  --  Brush Technology
Ph: +64 3 741 1204     Mobile: +64 21 238 7955
Web: brush.co.nz

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

C R
In reply to this post by Tavmjong Bah
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Vladimir Savic-3
In reply to this post by Tavmjong Bah
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Tavmjong Bah
In reply to this post by Eduard Braun
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Tavmjong Bah
In reply to this post by Vladimir Savic-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

C R
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Tavmjong Bah
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 <[hidden email]>
> 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
> > [hidden email]
> > 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Miguel Lopez
In reply to this post by C R

Yes, I did. Gonna forward this one to inkscape-devel. By the way, I would like to add I saw Tavmjong Bah's reply about the cores being used. Another question here, is Inkscape use only one core at this moment for everything? Then, if so, should threads settings be reduced to 2? If yes, why is there a option for more threads?


On 4/1/2017 6:17 AM, C R wrote:
Did you mean to reply to the list? :)

On 1 Apr 2017 01:44, "Miguel Lopez" <[hidden email]> wrote:
I use a i7 CPU, and it is 6-core/12 threads. As a matter of fact,
Inkscape seem to support at maximum of 8 threads and a rendering cache
of up to 4098 MB. Is that limitation addressed? As far as zooming level
go, rasterization of filters is how Illustrator managed to keep their
rendering speed quick as possible. But, I don't think it'll help too
much with the current Inkscape as it is now. They also support GPU
acceleration. I wonder if that's within any reach of Inkscape as of now.


On 3/31/2017 6:33 PM, 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.
>
> 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 <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Miguel Lopez
In reply to this post by Tavmjong Bah
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 <[hidden email]>
>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Yale Zhang
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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canvas tile size and rendering speed.

Miguel Lopez
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 <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>>> [hidden email]
>>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...