[Pixman] 0.29.2

[Søren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> On Sun, 27 Jan 2013 13:41:44 -0800
> Matt Turner <mattst88 at gmail.com> wrote:
>
>> On Sun, Jan 27, 2013 at 11:43 AM, Siarhei Siamashka
>> <siarhei.siamashka at gmail.com> wrote:
>> > Still, I'm not very happy about the code duplication. We already have
>> > similar iterators (fetch only, no writeback) in "pixman-mmx.c":
>> >
>> >     http://cgit.freedesktop.org/pixman/tree/pixman/pixman-mmx.c?id=pixman-0.28.2#n3904
>> >
>> > Ideally, a lot of this code can be reused in different backends. The
>> > only unique parts are just the fetch/store functions themselves.
>> 
>> I'm not sure I understand totally. Is the suggestion adding writeback
>> iterators, thereby allowing the removal of src_x888_0565?
>
> The writeback iterator is useful not only for src_x888_0565 removal
> (which is just a nice side effect). Whenever you are doing something
> with r5g6b5 destination, it is first fetched into a temporary buffer,
> modified and finally written back. If you don't provide an optimized
> writeback iterator, just C implementation is going to be used.
>
> But I tried to make another point. The iterators need a bit of support
> code, for example checking various flags and conditions. And a
> significant part of this support code might be possibly reused by
> different backends, avoiding unneeded duplication.

Yes, indeed. If a new new function type pixman_iter_initializer_t
(pixman_iter_t *iter) was introduced, it might be possible to have each
backend simply provide a table of

    { format, iter_flags, image_flags, iter_initializer }

and then have some function in pixman-implementation.c to do lookups in
these tables. A cache similar to the one for fast paths could be added.
There could then be utility functions for iterator initialization that
took a scanline accessor as a parameter.

This could also be used for the untransformed fetchers in
pixman-bits.c. These currently use the accessor functions cached in
bits_image_t, but if they became proper iterators, they could be
initialized with SIMD accessors instead. For NONE and PAD repeats,
they could also reuse the scanline buffer for all y values falling
outside the image grid.

Of course, I haven't tried implementing any of the above, so it may or
may not work out in practice.


Søren