Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Oded Gabbay]

On Fri, Jan 8, 2016 at 8:53 PM, Bill Spitzak  wrote:
>
>
> On Thu, Jan 7, 2016 at 11:44 PM, Pekka Paalanen  wrote:
>>
>>
>> Please keep in mind that the filters GOOD and BEST have been as is for
>> a long long time, AFAIU, so changing their behaviour now is likely not
>> a good idea. They are no longer "a good filter" and "whatever best
>> filter", but "the specific filter called GOOD" and "the specific filter
>> called BEST", in lack of documentation saying otherwise.
>
>
> Both GOOD and BEST are identical to BILINEAR in the current version of
> Pixman. Therefore anybody relying on the current behaviour can achieve it by
> using BILINEAR. In addition GOOD is unchanged for any scales larger than .75
> or for a scale of exactly .5.
>
> Also despite their names, bilinear in no way would be considered "good" or
> "best" by any sane person. We should not add illogical names (like NEW_GOOD
> or whatever) just because of paranoia over back-compatibility. It is also
> highly desirable that the default actually be "good", this cannot be done
> unless GOOD is changed, or the default is changed to "NEW_GOOD".
>
> This change was made to Cairo over a year ago with no complaints (except for
> speed issues, which this patch is necessary to solve by moving the fix from
> Cairo to Pixman). Lets get out of the dark ages, and stop doing things that
> are making open source desktops a laughingstock.
>

Hi Bill,
I just now read the new emails (I was on PTO for the last week).
It seems you found some mistakes and you want to resend a new version.
Did I understand you correctly ?
If that is indeed the case, then I prefer to wait for that version
(v9), and skip reviewing v8.
Please ack this.

Oded
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Bill Spitzak]

Yes I will try to send new versions asap.

Known mistakes/problems:

1. I was a bit too fast at deleting the recursion code for the linear
filters. The problems were not very visible with the 16-segment simpsons
integration, but obvious when reducing to 4 (which otherwise works in most
cases). Also it is actually easier to split with my new arguments to the
function, so I really should not have done that.

2. x.LINEAR where x is not IMPULSE or BOX or LINEAR is producing artefacts
that don't seem to exist in other combinations (or are much less visible in
other combinations?). I think I need to investigate this.

3. My comment is somewhat inaccurate and I need to update it. LINEAR.LINEAR
is only a cubic at scale==1, it is not possible to replicate what other
software calls "cubic" or "bicubic" using this

On Mon, Jan 11, 2016 at 1:16 AM, Oded Gabbay  wrote:

> On Fri, Jan 8, 2016 at 8:53 PM, Bill Spitzak  wrote:
> >
> >
> > On Thu, Jan 7, 2016 at 11:44 PM, Pekka Paalanen 
> wrote:
> >>
> >>
> >> Please keep in mind that the filters GOOD and BEST have been as is for
> >> a long long time, AFAIU, so changing their behaviour now is likely not
> >> a good idea. They are no longer "a good filter" and "whatever best
> >> filter", but "the specific filter called GOOD" and "the specific filter
> >> called BEST", in lack of documentation saying otherwise.
> >
> >
> > Both GOOD and BEST are identical to BILINEAR in the current version of
> > Pixman. Therefore anybody relying on the current behaviour can achieve
> it by
> > using BILINEAR. In addition GOOD is unchanged for any scales larger than
> .75
> > or for a scale of exactly .5.
> >
> > Also despite their names, bilinear in no way would be considered "good"
> or
> > "best" by any sane person. We should not add illogical names (like
> NEW_GOOD
> > or whatever) just because of paranoia over back-compatibility. It is also
> > highly desirable that the default actually be "good", this cannot be done
> > unless GOOD is changed, or the default is changed to "NEW_GOOD".
> >
> > This change was made to Cairo over a year ago with no complaints (except
> for
> > speed issues, which this patch is necessary to solve by moving the fix
> from
> > Cairo to Pixman). Lets get out of the dark ages, and stop doing things
> that
> > are making open source desktops a laughingstock.
> >
>
> Hi Bill,
> I just now read the new emails (I was on PTO for the last week).
> It seems you found some mistakes and you want to resend a new version.
> Did I understand you correctly ?
> If that is indeed the case, then I prefer to wait for that version
> (v9), and skip reviewing v8.
> Please ack this.
>
> Oded
>
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Bill Spitzak]

On Thu, Jan 7, 2016 at 11:44 PM, Pekka Paalanen  wrote:

>
> Please keep in mind that the filters GOOD and BEST have been as is for
> a long long time, AFAIU, so changing their behaviour now is likely not
> a good idea. They are no longer "a good filter" and "whatever best
> filter", but "the specific filter called GOOD" and "the specific filter
> called BEST", in lack of documentation saying otherwise.
>

Both GOOD and BEST are identical to BILINEAR in the current version of
Pixman. Therefore anybody relying on the current behaviour can achieve it
by using BILINEAR. In addition GOOD is unchanged for any scales larger than
.75 or for a scale of exactly .5.

Also despite their names, bilinear in no way would be considered "good" or
"best" by any sane person. We should not add illogical names (like NEW_GOOD
or whatever) just because of paranoia over back-compatibility. It is also
highly desirable that the default actually be "good", this cannot be done
unless GOOD is changed, or the default is changed to "NEW_GOOD".

This change was made to Cairo over a year ago with no complaints (except
for speed issues, which this patch is necessary to solve by moving the fix
from Cairo to Pixman). Lets get out of the dark ages, and stop doing things
that are making open source desktops a laughingstock.
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Pekka Paalanen]

On Thu, 7 Jan 2016 10:35:57 -0800
Bill Spitzak  wrote:

> You are right, I ran the tests on the earlier version of this code but not
> on the current one. There were very few tests of the separable filters,
> however, which is probably why it passed. Adding some tests would be nice,
> but only if we can prove that the resulting images are accurate (maybe by
> calculating them with a math program or something).

There are two different ways to test.

One is to hand-craft tests where you know what the correct result is,
and compare to the known correct answer. This takes a lot of work to
cover many parameter combinations.

Another is to test that the results do not change. Pixman uses this
method extensively with fuzzing: generate lots of pseudo-random
(repeatable) test cases and checksum over them all. When creating such
a test, you assume that the current implementation is correct and just
record the checksum as the correct result. It does not matter whether
it actually is correct or not: applications are already using Pixman and
perhaps relying on it, and you only care about finding changes. It is a
very good guard against regressions, but this method is not always
applicable.

The latter method is not applicable if one must allow some inaccuracy
in the results, like often with floating point operations. You could
still hand-craft some tests to ensure results don't change by assuming
that the current implementation is correct, saving what you get, and
comparing to that in the test. Proving correctness becomes a factor
only when you think the current code is not giving correct results or
you introduce a new feature.

I don't know what the case is here, but if it is possible to write
fuzzing tests, I would very much recommend that since it is pretty
easy. If not, then testing is more work.

The major users of Pixman that I know of are Xorg and Cairo. You are
familiar with Cairo at least, so if Xorg does not use these filtering
operations, there is probably less to worry about. I don't know what
Xorg uses, though.

Please keep in mind that the filters GOOD and BEST have been as is for
a long long time, AFAIU, so changing their behaviour now is likely not
a good idea. They are no longer "a good filter" and "whatever best
filter", but "the specific filter called GOOD" and "the specific filter
called BEST", in lack of documentation saying otherwise.


Thanks,
pq

> On Thu, Jan 7, 2016 at 12:09 AM, Pekka Paalanen  wrote:
> 
> > On Wed, 23 Dec 2015 10:08:01 +0200
> > Oded Gabbay  wrote:
> >  
> > > On Tue, Dec 22, 2015 at 10:53 PM, Bill Spitzak   
> > wrote:  
> > > > I think the improvement is obvious if you check how much code is run  
> > to do  
> > > > the Simpson's integration. BOX.BOX will literally be the filter used  
> > almost  
> > > > always once this is finally fixed.
> > > >  
> > >
> > > I understand the logic behind this, and I can agree with it, but the
> > > standard in pixman, AFAIK, is to show actual performance improvements
> > > using benchmarks/real-world cases.
> > >
> > > I'm not against this patch, and I think it will be eventually merged.
> > > I'm just saying I think we need to defer it until:
> > >
> > > 1. The changes you talk about them are actually merged into pixman &  
> > cairo  
> > > 2. We can show the (hopefully major) improvement using cairo  
> > benchmarking.
> >
> > Hi,
> >
> > some general comments:
> >
> > Not to forget, that any piece of existing code you replace should
> > already have a test excercising it in place, so that when you actually
> > change the code, the test ensures the effective result is still the
> > same. (The same does not necessarily imply correct, though. It's just
> > about catching unintended changes.)
> >
> > That should be pretty easy to check by deliberately breaking that piece
> > of code and seeing that 'make check' fails. If necessary, one can use
> > any of the PIXMAN_DISABLE options to force the use of generic code.
> >
> > Maybe this is already done and tested, but it would be nice to mention
> > it, so that the new people who don't know the test suite by heart are
> > assured it has been considered.
> >
> > If you find out that the test suite does not cover the code in
> > question, you may need to extend the test suite first.
> >
> > This policy would also highlight the cases where old code was actually
> > wrong and the tests ensure that it stays the same rather than correct.
> > Fixing this needs even more care as you want to check the new results
> > really are correct before fixing the test. One might also have to
> > consider if the old results are relied upon by the users like the Xorg
> > server, and the fix would break users. In that case the fix cannot land.
> >
> > Btw. the above is also a warning about changing the meaning of (the
> > numerical results produced by) existing filter flags. If e.g. Xorg
> > depends on some flag producing some 

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Bill Spitzak]

I think the improvement is obvious if you check how much code is run to do
the Simpson's integration. BOX.BOX will literally be the filter used almost
always once this is finally fixed.


On Tue, Dec 22, 2015 at 12:08 PM, Oded Gabbay  wrote:

> On Tue, Dec 22, 2015 at 9:44 PM, Bill Spitzak  wrote:
> > Any test using Cairo is not using this code for scaling down (since it
> uses
> > it's own filter generator, or older Cairo which only used bilinear) so I
> am
> > not sure if this case is being hit. If GOOD in the future produces
> BOX.BOX
> > then this will be hit a lot more often.
> >
> OK, got it. Thanks.
>
> So do you have some other case where you can demonstrate the
> effectiveness of this optimization ?
>
> If not, then I think we need to defer this patch until such a case
> arises, e.g. what you wrote about GOOD producing BOX.BOX in the
> future.
>
>Oded
>
> >
> >
> > On Tue, Dec 22, 2015 at 1:33 AM, Oded Gabbay 
> wrote:
> >>
> >> On Sat, Dec 12, 2015 at 8:06 PM,   wrote:
> >> > From: Bill Spitzak 
> >> >
> >> > This is easy as the caller already intersected the two boxes, so
> >> > the width is the integral.
> >> > ---
> >> >  pixman/pixman-filter.c | 5 +
> >> >  1 file changed, 5 insertions(+)
> >> >
> >> > diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
> >> > index 4aafa51..782f73d 100644
> >> > --- a/pixman/pixman-filter.c
> >> > +++ b/pixman/pixman-filter.c
> >> > @@ -182,6 +182,11 @@ integral (pixman_kernel_t reconstruct, double x1,
> >> > assert (width == 0.0);
> >> > return filters[sample].func (x2 / scale);
> >> >  }
> >> > +else if (reconstruct == PIXMAN_KERNEL_BOX && sample ==
> >> > PIXMAN_KERNEL_BOX)
> >> > +{
> >> > +   assert (width <= 1.0);
> >> > +   return width;
> >> > +}
> >> >  else if (sample == PIXMAN_KERNEL_IMPULSE)
> >> >  {
> >> > assert (width == 0.0);
> >> > --
> >> > 1.9.1
> >> >
> >> > ___
> >> > Pixman mailing list
> >> > Pixman@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/pixman
> >>
> >>
> >> As Soren said in his original email, this specialized case is
> >> justified if we can demonstrate an improvement in a real-world
> >> use-case, while making sure there aren't any other regressions.
> >>
> >> Generally speaking, when adding specific conditions to optimize code
> >> we need to see evidence that indeed the new code is faster in *most*
> >> cases. This is because even if the added conditions improve
> >> performance of a specific use-case, it might actually degrade
> >> performance on most other cases as they now need to do additional
> >> comparisons in every pass of this code.
> >>
> >> Therefore, I think we need to see some real numbers to accept this
> patch.
> >>
> >> fyi, I did a cairo benchmark run (on the trimmed benchmarks), and it
> >> was practically unchanged. When I checked the results with
> >> "--min-change 1%", I got:
> >>
> >> Speedups
> >> 
> >> image  t-firefox-canvas-swscroll  691.34 (701.92 1.30%) -> 678.93
> >> (693.67 1.25%):  1.02x speedup
> >>
> >> image t-firefox-fishtank  1611.65 (1640.22 1.23%) -> 1591.66
> >> (1653.68 1.91%):  1.01x speedup
> >>
> >> Slowdowns
> >> =
> >> image t-gnome-system-monitor  886.06 (893.33 1.20%) -> 895.76
> >> (903.89 1.32%):  1.01x slowdown
> >>
> >> image t-firefox-fishbowl  3242.06 (3280.91 0.55%) -> 3284.20
> >> (3285.17 0.08%):  1.01x slowdown
> >>
> >> imaget-evolution  335.63 (337.11 0.28%) -> 340.48
> >> (352.97 1.62%):  1.01x slowdown
> >>
> >> imaget-xfce4-terminal-a1  554.95 (572.35 1.59%) -> 563.67
> >> (582.91 1.62%):  1.02x slowdown
> >>
> >> image   t-gnome-terminal-vim  354.85 (358.67 0.67%) -> 364.49
> >> (366.12 0.33%):  1.03x slowdown
> >>
> >>   Oded
> >
> >
>
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Oded Gabbay]

On Tue, Dec 22, 2015 at 9:44 PM, Bill Spitzak  wrote:
> Any test using Cairo is not using this code for scaling down (since it uses
> it's own filter generator, or older Cairo which only used bilinear) so I am
> not sure if this case is being hit. If GOOD in the future produces BOX.BOX
> then this will be hit a lot more often.
>
OK, got it. Thanks.

So do you have some other case where you can demonstrate the
effectiveness of this optimization ?

If not, then I think we need to defer this patch until such a case
arises, e.g. what you wrote about GOOD producing BOX.BOX in the
future.

   Oded

>
>
> On Tue, Dec 22, 2015 at 1:33 AM, Oded Gabbay  wrote:
>>
>> On Sat, Dec 12, 2015 at 8:06 PM,   wrote:
>> > From: Bill Spitzak 
>> >
>> > This is easy as the caller already intersected the two boxes, so
>> > the width is the integral.
>> > ---
>> >  pixman/pixman-filter.c | 5 +
>> >  1 file changed, 5 insertions(+)
>> >
>> > diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
>> > index 4aafa51..782f73d 100644
>> > --- a/pixman/pixman-filter.c
>> > +++ b/pixman/pixman-filter.c
>> > @@ -182,6 +182,11 @@ integral (pixman_kernel_t reconstruct, double x1,
>> > assert (width == 0.0);
>> > return filters[sample].func (x2 / scale);
>> >  }
>> > +else if (reconstruct == PIXMAN_KERNEL_BOX && sample ==
>> > PIXMAN_KERNEL_BOX)
>> > +{
>> > +   assert (width <= 1.0);
>> > +   return width;
>> > +}
>> >  else if (sample == PIXMAN_KERNEL_IMPULSE)
>> >  {
>> > assert (width == 0.0);
>> > --
>> > 1.9.1
>> >
>> > ___
>> > Pixman mailing list
>> > Pixman@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/pixman
>>
>>
>> As Soren said in his original email, this specialized case is
>> justified if we can demonstrate an improvement in a real-world
>> use-case, while making sure there aren't any other regressions.
>>
>> Generally speaking, when adding specific conditions to optimize code
>> we need to see evidence that indeed the new code is faster in *most*
>> cases. This is because even if the added conditions improve
>> performance of a specific use-case, it might actually degrade
>> performance on most other cases as they now need to do additional
>> comparisons in every pass of this code.
>>
>> Therefore, I think we need to see some real numbers to accept this patch.
>>
>> fyi, I did a cairo benchmark run (on the trimmed benchmarks), and it
>> was practically unchanged. When I checked the results with
>> "--min-change 1%", I got:
>>
>> Speedups
>> 
>> image  t-firefox-canvas-swscroll  691.34 (701.92 1.30%) -> 678.93
>> (693.67 1.25%):  1.02x speedup
>>
>> image t-firefox-fishtank  1611.65 (1640.22 1.23%) -> 1591.66
>> (1653.68 1.91%):  1.01x speedup
>>
>> Slowdowns
>> =
>> image t-gnome-system-monitor  886.06 (893.33 1.20%) -> 895.76
>> (903.89 1.32%):  1.01x slowdown
>>
>> image t-firefox-fishbowl  3242.06 (3280.91 0.55%) -> 3284.20
>> (3285.17 0.08%):  1.01x slowdown
>>
>> imaget-evolution  335.63 (337.11 0.28%) -> 340.48
>> (352.97 1.62%):  1.01x slowdown
>>
>> imaget-xfce4-terminal-a1  554.95 (572.35 1.59%) -> 563.67
>> (582.91 1.62%):  1.02x slowdown
>>
>> image   t-gnome-terminal-vim  354.85 (358.67 0.67%) -> 364.49
>> (366.12 0.33%):  1.03x slowdown
>>
>>   Oded
>
>
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Bill Spitzak]

Any test using Cairo is not using this code for scaling down (since it uses
it's own filter generator, or older Cairo which only used bilinear) so I am
not sure if this case is being hit. If GOOD in the future produces BOX.BOX
then this will be hit a lot more often.


On Tue, Dec 22, 2015 at 1:33 AM, Oded Gabbay  wrote:

> On Sat, Dec 12, 2015 at 8:06 PM,   wrote:
> > From: Bill Spitzak 
> >
> > This is easy as the caller already intersected the two boxes, so
> > the width is the integral.
> > ---
> >  pixman/pixman-filter.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
> > index 4aafa51..782f73d 100644
> > --- a/pixman/pixman-filter.c
> > +++ b/pixman/pixman-filter.c
> > @@ -182,6 +182,11 @@ integral (pixman_kernel_t reconstruct, double x1,
> > assert (width == 0.0);
> > return filters[sample].func (x2 / scale);
> >  }
> > +else if (reconstruct == PIXMAN_KERNEL_BOX && sample ==
> PIXMAN_KERNEL_BOX)
> > +{
> > +   assert (width <= 1.0);
> > +   return width;
> > +}
> >  else if (sample == PIXMAN_KERNEL_IMPULSE)
> >  {
> > assert (width == 0.0);
> > --
> > 1.9.1
> >
> > ___
> > Pixman mailing list
> > Pixman@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/pixman
>
>
> As Soren said in his original email, this specialized case is
> justified if we can demonstrate an improvement in a real-world
> use-case, while making sure there aren't any other regressions.
>
> Generally speaking, when adding specific conditions to optimize code
> we need to see evidence that indeed the new code is faster in *most*
> cases. This is because even if the added conditions improve
> performance of a specific use-case, it might actually degrade
> performance on most other cases as they now need to do additional
> comparisons in every pass of this code.
>
> Therefore, I think we need to see some real numbers to accept this patch.
>
> fyi, I did a cairo benchmark run (on the trimmed benchmarks), and it
> was practically unchanged. When I checked the results with
> "--min-change 1%", I got:
>
> Speedups
> 
> image  t-firefox-canvas-swscroll  691.34 (701.92 1.30%) -> 678.93
> (693.67 1.25%):  1.02x speedup
>
> image t-firefox-fishtank  1611.65 (1640.22 1.23%) -> 1591.66
> (1653.68 1.91%):  1.01x speedup
>
> Slowdowns
> =
> image t-gnome-system-monitor  886.06 (893.33 1.20%) -> 895.76
> (903.89 1.32%):  1.01x slowdown
>
> image t-firefox-fishbowl  3242.06 (3280.91 0.55%) -> 3284.20
> (3285.17 0.08%):  1.01x slowdown
>
> imaget-evolution  335.63 (337.11 0.28%) -> 340.48
> (352.97 1.62%):  1.01x slowdown
>
> imaget-xfce4-terminal-a1  554.95 (572.35 1.59%) -> 563.67
> (582.91 1.62%):  1.02x slowdown
>
> image   t-gnome-terminal-vim  354.85 (358.67 0.67%) -> 364.49
> (366.12 0.33%):  1.03x slowdown
>
>   Oded
>
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[Oded Gabbay]

On Sat, Dec 12, 2015 at 8:06 PM,   wrote:
> From: Bill Spitzak 
>
> This is easy as the caller already intersected the two boxes, so
> the width is the integral.
> ---
>  pixman/pixman-filter.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
> index 4aafa51..782f73d 100644
> --- a/pixman/pixman-filter.c
> +++ b/pixman/pixman-filter.c
> @@ -182,6 +182,11 @@ integral (pixman_kernel_t reconstruct, double x1,
> assert (width == 0.0);
> return filters[sample].func (x2 / scale);
>  }
> +else if (reconstruct == PIXMAN_KERNEL_BOX && sample == PIXMAN_KERNEL_BOX)
> +{
> +   assert (width <= 1.0);
> +   return width;
> +}
>  else if (sample == PIXMAN_KERNEL_IMPULSE)
>  {
> assert (width == 0.0);
> --
> 1.9.1
>
> ___
> Pixman mailing list
> Pixman@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pixman


As Soren said in his original email, this specialized case is
justified if we can demonstrate an improvement in a real-world
use-case, while making sure there aren't any other regressions.

Generally speaking, when adding specific conditions to optimize code
we need to see evidence that indeed the new code is faster in *most*
cases. This is because even if the added conditions improve
performance of a specific use-case, it might actually degrade
performance on most other cases as they now need to do additional
comparisons in every pass of this code.

Therefore, I think we need to see some real numbers to accept this patch.

fyi, I did a cairo benchmark run (on the trimmed benchmarks), and it
was practically unchanged. When I checked the results with
"--min-change 1%", I got:

Speedups

image  t-firefox-canvas-swscroll  691.34 (701.92 1.30%) -> 678.93
(693.67 1.25%):  1.02x speedup

image t-firefox-fishtank  1611.65 (1640.22 1.23%) -> 1591.66
(1653.68 1.91%):  1.01x speedup

Slowdowns
=
image t-gnome-system-monitor  886.06 (893.33 1.20%) -> 895.76
(903.89 1.32%):  1.01x slowdown

image t-firefox-fishbowl  3242.06 (3280.91 0.55%) -> 3284.20
(3285.17 0.08%):  1.01x slowdown

imaget-evolution  335.63 (337.11 0.28%) -> 340.48
(352.97 1.62%):  1.01x slowdown

imaget-xfce4-terminal-a1  554.95 (572.35 1.59%) -> 563.67
(582.91 1.62%):  1.02x slowdown

image   t-gnome-terminal-vim  354.85 (358.67 0.67%) -> 364.49
(366.12 0.33%):  1.03x slowdown

  Oded
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

[Pixman] [PATCH 07/15] pixman-filter: Speed up the BOX+BOX filter

[spitzak]

From: Bill Spitzak 

This is easy as the caller already intersected the two boxes, so
the width is the integral.
---
 pixman/pixman-filter.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 4aafa51..782f73d 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -182,6 +182,11 @@ integral (pixman_kernel_t reconstruct, double x1,
assert (width == 0.0);
return filters[sample].func (x2 / scale);
 }
+else if (reconstruct == PIXMAN_KERNEL_BOX && sample == PIXMAN_KERNEL_BOX)
+{
+   assert (width <= 1.0);
+   return width;
+}
 else if (sample == PIXMAN_KERNEL_IMPULSE)
 {
assert (width == 0.0);
-- 
1.9.1

___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman