> Also, I would write the code like this:
>
> pixman_fixed_t error = pixman_fixed_1 - new_total;
> for (x = 0; x < width; ++x)
> {
> pixman_fixed_t d = error * (x + 1) / width;
> p[x] += d;
> error -= d;
> }
>
> to get rid of the t
> This makes the speed of the demo more accurate, as the filter generation
> is a visible fraction of the time it takes to do a transform. This also
> prevents the output of unused filters in the gnuplot option in the next
> patch.
>
> Note this is not dependent on other patches, as use can choose
Generalize and simplify the code that reduces BILINEAR to NEAREST so
that all the reduction happens for all affine transformations where
t00..t12 are integers and (t00 + t01) and (t10 + t11) are both
odd. This is a sufficient condition for the resulting transformed
coordinates to be exactly at the
Reviewed-by: Soren Sandmann
On Sun, Mar 6, 2016 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> It now shows the initial value of 4 when the demo is started
>
> Signed-off-by: Bill Spitzak
> ---
> demos/scale.ui | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/demos/scale.ui b/demos/sca
Looks correct to me, and a really good idea. I noticed this but did not
know how to fix it, so I had to make sure only one optimization flag was
turned on. The ability to turn on multiple ones is a lot better.
On Wed, Mar 16, 2016 at 9:14 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wro
> +*
>> +* and the destination coordinates are (n + 0.5, m + 0.5).
>> Then
>> +* the transformed x coordinate is:
>> +*
>> +* tx = t00 * (n + 0.5) + t01 * (m + 0.5) + t02
>> +*= t00 * n + t01 * m + t02 + (t00 + t01)
I suppose it's a little illogical that scale_x and scale_y really are the
reciprocal values of how much the source image should be scaled. I don't
remember exactly what I was thinking, but it might have something like
"this allows you to just pass t[0][0] and t[1][1] if you have a pure
scaling, whi
When a BILINEAR filter is reduced to NEAREST, it is possible for both
types of fast paths to run; in this case, the NEAREST ones should be
preferred as that is the simpler filter.
Signed-off-by: Soren Sandmann
---
pixman/pixman-fast-path.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
Reviewed-by: Soren Sandmann
On Sun, Mar 6, 2016 at 8:06 PM, wrote:
> From: Bill Spitzak
>
> Signed-off-by: Bill Spitzak
> ---
> demos/scale.ui | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/demos/scale.ui b/demos/scale.ui
> index 6028ab7..7e999c1 100644
> --- a/demos/scale.ui
> ++
Looks good to me
On Wed, Mar 16, 2016 at 9:14 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wrote:
> Generalize and simplify the code that reduces BILINEAR to NEAREST so
> that all the reduction happens for all affine transformations where
> t00..t12 are integers and (t00 + t01) and (t1
On Thu, Mar 17, 2016 at 10:06 PM, Søren Sandmann
wrote:
> I suppose it's a little illogical that scale_x and scale_y really are the
> reciprocal values of how much the source image should be scaled. I don't
> remember exactly what I was thinking, but it might have something like
> "this allows yo
This new test tests a bunch of bilinear downscalings, where many have
a transformation such that the BILINEAR filter can be reduced to
NEAREST (and many don't).
A CRC32 is computed for all the resulting images and compared to a
known-good value for both 4-bit and 7-bit interpolation.
V2: Remove l
12 matches
Mail list logo
