[Pixman] [PATCH] spans

[Chris Wilson]

On Mon, 22 Aug 2011 19:28:13 +0900, Taekyun Kim <podain77 at gmail.com> wrote:
Non-text part: multipart/alternative
> On 08/21/2011 04:54 AM, Chris Wilson wrote:
> >  From which I can see that there is potential here, but it is dwarfed by the
> > overheads in the current implementation. My next step is to change the
> > rasterisers to spit out a RLE scanline in the form of (count, opacity[],
> > runs[]) and pass the arrays of spans to pixman. I felt this would be a
> > more invasive change and so avoided it... Suggestions very welcome.
> >
> 
> Which part do you think consumes most of the time? Fast paths are not 
> optimised
> for width of 1. Per-pixel function calls are also significant overhead.

Indeed thats my biggest concern at the moment. Also per-pixel setup such
as preping the solid color. The malloc of the compositor is also an
issue.

> Maybe RLE encoding of spans gives more chance of optimization to pixman.
> Internally, we can avoid per-pixel composite function calls by building 
> a8 mask of
> some portion of spans which contain non-opaque runs while remaining opaque
> runs can avoid using a8 mask.

The disadvantage is that we have to rework and add a second set of
fast-paths. The first step is to simply move the span-to-composite
routines into pixman.

pixman_compositor_init (&compositor, op, src, mask, dst, etc...)
pixman_compositor_blt (&compositor,
		       int32_t y, int32_t height,
		       int32_t x[], uint8_t alpha[], int count);

> Some other options can be light-weighted pixel composite function. We know
> that we would composite only a single pixel for a function call for 
> non-opaque
> runs, so we don't expect any loop handling or setting up overhead.

I had a very quick look at this, by adding a set of WIDTH_x flags.
It does improve the situation, but not dramatically.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre