<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 08/21/2011 04:54 AM, Chris Wilson wrote: <blockquote cite="mid:1313870060-30919-1-git-send-email-chris@chris-wilson.co.uk" type="cite"> <pre wrap="">Taekjun Kim made a good suggestion on how to eliminate the majority of the noise in the previous patch: simply handle opacity by first combining (mask IN opacity) in the general_composite_rect. The rest of the patch is then updating the internal API to propagate an opacity value from the new public interface. After a couple of weeks of work on the consumer of that public API, I've concluded that the minimal interface of adding a single opacity value that is equivalent to a mask is the simplest and yet complete enough for use by cairo to implement clipped shapes with an unbounded operator with no less efficiency than for bounded operations. (For the unbounded case, we create a second compositor using OUT_REVERSE with WHITE and select the compositor based on a bit in the span that indicates whether that span is inside/outside the shape.) </pre> </blockquote> Because LERP is a ternary operator, we cannot simply replace "OP" by "LERP" in equation "(src IN mask) OP dst". So we have to regard whole equation as OP itself. For example, Definition of PIXMAN_OP_OVER : (src IN mask) OVER dst Definition of PIXMAN_OP_LERP : src LERP_mask dst Now we have to add the opacity. If we regard opacity as part of src, we can replace "src" with "src IN opacity" in the above example equation. In the case of mask, we can replace "mask" with "opacity IN mask". To do single-pass polygon filling including clipping, as you mentioned, "src LERP_(opacity IN mask) dst" would be good for operator SOURCE. <blockquote cite="mid:1313870060-30919-1-git-send-email-chris@chris-wilson.co.uk" type="cite"> <pre wrap="">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. </pre> </blockquote> 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. 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. 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 have to think more about the efficient way of passing shape information to pixman. -- Best Regards, Taekyun Kim </body> </html>