Re: Pixman Speed (Re: gallium surface still maintained ?)

No, convolution is absolutely not the fastest thing possible. Right
now it does n^2 operations per output pixel, even when using the
"2-pass" api. Also changing the size of the filter requires
recalculation and replacement of a large array of filter kernels. This
is for transformations, but I believe the same problem applies to
convolution kernels.

I have been trying to update this for about 2 years now but not having
much luck, as the first step is to get "good" and "best" to actually
do something, so there is a api that is not locked to a particular
implementation or filter. Any fast filtering is going to be locked to
a small set of implementation-defined filters that will prevent any
possible "define the filter" api that seems to be preferred by the
current Pixman maintainers. However so far any attempts to do this
have been rejected.

Convolution filters have the same problem. Blurs can be vastly sped up
by scaling the image down before blurring, but this puts restrictions
on the filter shape so that the current "caller defines the filter"
api will not work.



On Fri, Aug 5, 2016 at 7:08 PM, Lawrence D'Oliveiro
<[email protected]> wrote:
> On Fri, 5 Aug 2016 22:40:22 +0200, Petr Kobalíček wrote:
>
>> I think it's not bad if I consider how much architecture-specific
>> code is in pixman, for example.
>
> Speaking of which, is Pixman as fast as it can be? I ask because I see
> some breathtaking effects running in real time in screen savers, yet
> when I try to do what I thought were similar convolution effects using
> Pixman
> <http://default-cube.deviantart.com/gallery/54316106/Python-Pixman-Examples>,
> they seem to take ages to render.
> --
> cairo mailing list
> [email protected]
> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo