[cairo] Special case pixman_rasterize_trapezoid() for boxes

[Soeren Sandmann]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> Hi all,
> 
> I'd like some feedback on the sanity of adding a special case inside
> pixman_rasterize_trapezoid() for the rectilinear condition. In
> particular, guidance on handling the 1/8 bpp cases.

Well, I can't say I'm very thrilled about fast pathing in the
trapezoid code, when trapezoids are increasingly becoming
irrelevant. But on the other hand, we don't have a polygon rasterizer
in pixman yet, and nobody knows if or when we will, so given that,
speeding up the rectilinear case probably does make sense if there are
signifcant time savings to be had. If we end up doing this, it would
have to happen after 0.16.0.

A couple of specific comments:

- Given that this is a fast path, I'm not sure it makes sense to worry
  about the accessor case. If each pixel goes through an indirect
  function call, performance will never be great. So maybe only do
  this when PIXMAN_FB_ACCESSORS is not defined

- Are any other cases than 8bpp actually interesting? Ie., are there
  real-world cases where people use the trapezoid code to draw lots of
  rectangles on an a1 surface?

- In general, I don't trust the numbers from callgrind very much. As
  far as I know callgrind doesn't take memory access into account, so
  the numbers don't correspond very well to wall clock time which is
  often dominated by memory bandwidth and/or latency.

  Both oprofile and sysprof produce more accurate numbers, but even so
  there is no real substitute for measuring the actual real time
  savings.


Thanks,
Soren