<!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 09/17/2011 12:29 AM, Søren Sandmann wrote: <blockquote cite="mid:ye8d3f0ijyr.fsf@llama15.cs.au.dk" type="cite"> <pre wrap="">Chris Wilson <a class="moz-txt-link-rfc2396E" href="mailto:chris@chris-wilson.co.uk"><chris@chris-wilson.co.uk></a> writes: </pre> <blockquote type="cite"> <pre wrap="">On Thu, 15 Sep 2011 13:26:09 +0200, <a class="moz-txt-link-abbreviated" href="mailto:sandmann@cs.au.dk">sandmann@cs.au.dk</a> (=?utf-8?Q?S=C3=B8ren?= Sandmann) wrote: </pre> <blockquote type="cite"> <pre wrap="">Chris Wilson <a class="moz-txt-link-rfc2396E" href="mailto:chris@chris-wilson.co.uk"><chris@chris-wilson.co.uk></a> writes: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Did you see Taekyun Kim's reply to this? He proposes this API: pixman_image_composite_xrender(op, src, shape, clip, dst) pixman_image_composite_bounded(op, src, shape, clip, dst) pixman_image_composite_simple(op, src, shape, clip, dst) instead, which would add direct one-pass support for all of cairo's compositing schemes, including clip masks. </pre> </blockquote> <pre wrap=""> You're encoding operator semantics into the function call and adding parameters for the rest? </pre> </blockquote> <pre wrap=""> Yes, basically. It's more or less a direct translation of the three compositing equations that cairo uses into function calls. </pre> </blockquote> <pre wrap=""> But why three functions when the difference is the semantics of the operator. Just allow Cairo to pick the operator that corresponds to Cairo's interpretation of op + mask + clip. </pre> </blockquote> <pre wrap=""> I guess that makes sense. I'll take a look at the patch sometime next week. Soren </pre> </blockquote> What I think as "best" is that pixman can take "compositing expression tree" via either "compositing program" or "deferred compositing (like GPU)". Those three interfaces are just examples of compositing equations pixman can support for cairo by introducing some additional features i.e. LERP. My question is then "such extension might be sufficient or not". What I want to achieve is that "plot a pixel if and only if it is visible". I believe we need compositing expression tree to achieve this. That would be the right direction in the long run. Anyway, for our current purpose, encoding semantics into OP seem to be a better way. I'm not opposed to this and I will make fast paths for LERP if these patches get in upstream. -- Best Regards, Taekyun Kim </body> </html>