<!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"> I've looked into Chris's initial version and can give leave some comments. And I also have some questions about pixman polygon image to <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">Søren in below comments. So, let's start. On 08/01/2011 08:49 PM, <a class="moz-txt-link-abbreviated" href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a> wrote: <blockquote cite="mid:e0d58a$v8rtr@orsmga002.jf.intel.com" type="cite"> <pre wrap="">Currently Cairo generates a temporary alpha mask for any non-pixel aligned shape. In those circumstances, it would be faster if we could pass the shape-information to pixman and have it composite in a single-operation. (With secondary benefits for reducing the number of sampled pixels.) A further goal is to be able to reduce the unaligned clipping operation to a single pass as well. Furthermore it will also be useful to supply a unified-opacity value to support a "global alpha" when our source/mask channels are already utilised. One suggested approach is to create a polygon image and have pixman generate spans internally. This satisfies compositing a polygon in a single pass, and if we additionally add clip-polygons we can accomplish the further goal of single-pass clipping as well. </pre> </blockquote> I totally agree with that current pixman interface is not sufficient for efficient polygon scan rasterizaion. Sampling every pixels inside of mask extents is huge overhead. And some applications require additional global opacity to be applied while mask is used for some other purposes. With current pixman, we have to do this by rendering things into a temp image and then compositing to destination with solid mask with opacity alpha value (multi-pass). Currently, there are two approaches to support polygon filling. pixman polygon image vs spans. I think pixman polygon image is a vector representation of an alpha mask. I have several questions to s<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">øren about polygon image. 1. If polygon image is used as a src, is it treated as just a8 image? 2. If polygon image is used as a dest, is it converted to bits image? 3. What if pixman_image_get_data() is called on polygon image? 4. How can I fill intersection of two (or more) polygon images? Extra note: If we want pixman to be more powerful and general stateless backend for vector and raster graphics library, I think it would be good to introduce GPU-backend with pixman path image. That can give us full chance of optimizing shape filling pipeline. But if we consider S/W rendering only, polygon image would be sufficient. I don't think that those two approaches are conflicting. We can support both interfaces. Each of them have pros and cons. <blockquote cite="mid:e0d58a$v8rtr@orsmga002.jf.intel.com" type="cite"> <pre wrap="">I've push an intiial implementation to git://people.freedesktop.org/~ickle/pixman wip/spans git://people.freedesktop.org/~ickle/cairo wip/spans </pre> </blockquote> As I mentioned on IRC, general paths can be implemented by simply applying combine_in just before giving scanlines to composite function if opacity is not fully opaque. I think people will not want performance regressions even on general paths. And some additional mechanisms seem to be needed to utilize existing fast paths. Fast paths for solid mask can be reused to support opacity by simply combining solid color with opacity value. Solid mask is also same. Adding fast paths with non-solid mask and non-opaque opacity should be sufficient for our requirement. For example, over_n_8_8888 does not need to have FAST_PATH_IS_OPAQUE flag if the function internally pre-combine opacity with solid color. Your C fast paths can be modified to take advantage of existing fast paths with small amount of effort. <blockquote cite="mid:e0d58a$v8rtr@orsmga002.jf.intel.com" type="cite"> <pre wrap="">Even without optimised fast-paths, there are quite a few traces where passing spans to pixman is a win (where the shape only occupies a fraction of the mask extents and so where doing so reduces the number of pixels we have to sample; and the opaque portions still hit the existing fast paths.) -Chris </pre> </blockquote> I will also evaluate the performance of HTML5 canvas bench. Thank you Chris! -- Best Regards, Taekyun Kim </body> </html>