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:
The problem is that *Cairo* does not call this function. This is because
Cairo already has my patches which work around the broken filtering by
generating it's own filtering. The whole point of this series of patches is
so that this work-around can be removed from Cairo.
On Tue, Dec 22, 2015 at 1
On Tue, Dec 22, 2015 at 9:25 PM, Bill Spitzak wrote:
>
>
> On Tue, Dec 22, 2015 at 2:32 AM, Oded Gabbay wrote:
>>
>> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
>> > From: Bill Spitzak
>> >
>> > The other filters don't range-check, so there is no need for this
>> > one to either. It is only called
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
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 A
On Tue, Dec 22, 2015 at 1:38 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > Only LINEAR is not differentiable at zero,
>
> I'm sorry, I don't understand this sentence. Could you please give me
> a more detailed explanation + reference ?
>
All t
On Tue, Dec 22, 2015 at 2:32 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > The other filters don't range-check, so there is no need for this
> > one to either. It is only called with x==0.
>
> Actually, I tried to stop at this function in gdb a
This is forcing the filter to be normalized (sum to 1.0) despite any math
errors.
p is a post-increment pointer used to store the filter values, so it now
points after the last filter value. The filter is summed and the difference
from 1.0 is then added to the middle pixel with this code.
If the
On Tue, Dec 22, 2015 at 4:21 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > With the other patch to put error on the center pixel, this produces
> > the same result as BOX.IMPULSE filter.
> > ---
> > pixman/pixman-filter.c | 2 ++
> > 1 file ch
On Tue, Dec 22, 2015 at 4:38 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > The other filters do not check for x being in range, so there is
> > no reason for cubic to do so.
>
> This argument is a bit problematic.
> We could also argue that thi
On Tue, Dec 22, 2015 at 4:44 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > If sample is IMPULSE and reconstruct is BOX or IMPULSE the sub-pixel
> > position of the sample is not relevant, so only one subsample is needed.
> Why ?
> I mean why it
On Wed, Dec 9, 2015 at 10:28 AM, Oded Gabbay wrote:
> Hi All,
>
> I'm planning to release a new pixman development version (0.33.6) on
> 12/16. Immediately after that, I'm going to create a new stable branch
> - 0.34.
>
> Once that happen, only fixes will be accepted to that branch until the
> sta
A new pixman development release 0.33.6 is now available. This is the final
release candidate leading up to the 0.34 stable release. The stable release is
expected to be announced at the end of January 2016.
From this point forward, only bug fixes can be accepted to the 0.34 release.
This rele
On Thu, Jun 4, 2015 at 12:02 PM, Andrea Canciani wrote:
> The patch does not regress the mingw-based build (basically that used in
> http://cairographics.org/end_to_end_build_for_win32/ )
> I did not manage to get the build working on the cmd.exe shell. Do you have
> any instructions (or possibly
Hi Nemanja,
I would like to clean pixman's patchwork and you have about 10
outstanding patches.
Could you please take a look and tell me which ones are still relevant
and which ones are not ?
You can take a look at http://patchwork.freedesktop.org/project/pixman/patches/
I also copied here there
Hi Ben,
I would like to clean pixman's patchwork and you have about 20
outstanding patches.
Could you please take a look and tell me which ones are still relevant
and which ones are not ?
You can take a look at http://patchwork.freedesktop.org/project/pixman/patches/
I also copied here there nam
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> If sample is IMPULSE and reconstruct is BOX or IMPULSE the sub-pixel
> position of the sample is not relevant, so only one subsample is needed.
Why ?
I mean why it is not relevant ? and why only one subsample is needed ?
Oded
> --
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> The other filters do not check for x being in range, so there is
> no reason for cubic to do so.
This argument is a bit problematic.
We could also argue that this filter was actually implemented
correctly/more robust and we should
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> With the other patch to put error on the center pixel, this produces
> the same result as BOX.IMPULSE filter.
> ---
> pixman/pixman-filter.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/pixman/pixman-filter.c b/pixma
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> Any error in filter normalization is placed on the center of odd-sized
> filters,
> rather than 1 pixel to the right.
>
> In particular this fixes the 1-wide filters produced by impulse sampling
> so they are 1.0 rather than 0.0.
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> The other filters don't range-check, so there is no need for this
> one to either. It is only called with x==0.
Actually, I tried to stop at this function in gdb and didn't manage to
do it (using the scale demo). I then looked at
On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> Only LINEAR is not differentiable at zero,
I'm sorry, I don't understand this sentence. Could you please give me
a more detailed explanation + reference ?
Thanks,
Oded
> so only do the recursive split of the integral fo
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-filt
23 matches
Mail list logo
