Add iterators in the general implementation
authorSøren Sandmann Pedersen <ssp@redhat.com>
Fri, 10 Dec 2010 16:30:27 +0000 (11:30 -0500)
committerSøren Sandmann Pedersen <ssp@redhat.com>
Tue, 18 Jan 2011 17:42:25 +0000 (12:42 -0500)
commit15b1645c7b96498788c9376e3bb7d8a5e7b4e584
tree291f9c0f78727bfb70ab23df74a55ce72c6a7f54
parent255d624e508e29b452e567c249ac75ae8d8e2abe
Add iterators in the general implementation

We add a new structure called a pixman_iter_t that encapsulates the
information required to read scanlines from an image. It contains two
functions, get_scanline() and write_back(). The get_scanline()
function will generate pixels for the current scanline. For iterators
for source images, it will also advance to the next scanline. The
write_back() function is only called for destination images. Its
function is to write back the modified pixels to the image and then
advance to the next scanline.

When an iterator is initialized, it is passed this information:

   - The image to iterate

   - The rectangle to be iterated

   - A buffer that the iterator may (but is not required to) use. This
     buffer is guaranteed to have space for at least width pixels.

   - A flag indicating whether a8r8g8b8 or a16r16g16b16 pixels should
     be fetched

There are a number of (eventual) benefits to the iterators:

   - The initialization of the iterator can be virtualized such that
     implementations can plug in their own CPU specific get_scanline()
     and write_back() functions.

   - If an image is horizontal, it can simply plug in an appropriate
     get_scanline(). This way we can get rid of the annoying
     classify() virtual function.

   - In general, iterators can remember what they did on the last
     scanline, so for example a REPEAT_NONE image might reuse the same
     data for all the empty scanlines generated by the zero-extension.

   - More detailed information can be passed to iterator, allowing
     more specialized fetchers to be used.

   - We can fix the bug where destination filters and transformations
     are not currently being ignored as they should be.

However, this initial implementation is not optimized at all. We lose
several existing optimizations:

   - The ability to composite directly in the destination
   - The ability to only fetch one scanline for horizontal images
   - The ability to avoid fetching the src and mask for the CLEAR
     operator

Later patches will re-introduce these optimizations.
pixman/pixman-general.c