Hi Pekka, Can't be this solved by creating a subimage based on the input image and the viewport? This way you can basically use the same pipeline. I'm not sure, however, if I fully understand the issue.
Cheers, Petr On Tue, Mar 3, 2015 at 8:49 AM, Pekka Paalanen <[email protected]> wrote: > On Mon, 2 Mar 2015 17:33:16 +0200 > Siarhei Siamashka <[email protected]> wrote: > > > On Mon, 2 Mar 2015 14:47:01 +0200 > > Pekka Paalanen <[email protected]> wrote: > > > > > Hi, > > > > > > I've been trying to use source clipping in Weston's Pixman-renderer, > > > and I found something that seems strange. > > > > > > The scenario is that I have: > > > - source clip in source image coordinates > > > - transformation (matrix) > > > - destination clip in destination coordinates > > > - potentially a mask (to apply global alpha > > > > > > Then call pixman_image_composite32() to render. > > > > > > Apart from the source clip everything works fine. Some special cases > > > really need a source clip, so I'm looking into that. I finally realized > > > I need all three to actually get any effect: > > > > > > pixman_image_set_clip_region32(ps->image, &buffer_region); > > > pixman_image_set_source_clipping(ps->image, 1); > > > pixman_image_set_has_client_clip(ps->image, 1); > > > > > > It seems that is as designed, that's ok. > > > > > > The strange thing is that the source clip seems to be done in > > > the destination, not in the source. Is this expected? > > > > Yes, this is expected. Søren can probably provide better explanations > > about the rationale. But here are some old links: > > > > http://lists.cairographics.org/archives/xorg-devel/2009-May/000819.html > > http://lists.cairographics.org/archives/xorg-devel/2009-May/000820.html > > > http://cgit.freedesktop.org/pixman/commit/?id=78ca4eea6467dbb6b9da1198b9526750a0a8dca3 > > Hi Siarhei, > > thank you for the fast response. I did suspect the Pixman API behaviour > to be intricately tied to something in X11, and those pointers confirm > it. Now I know what the API intends. > > > > Using source clip looks like it replaces the destination clip, instead > > > of clipping in the source image coordinate space. I'm testing with > > > Pixman 0.32.4. > > > > > > I would really need clipping both before and after the transformation. > > > Is there a way to achieve that, or do I have to start looking into > > > trapezoids or something? (I suppose I will next look into creating a > > > mask image.) > > > > Can you provide a bit more details about your exact use case? > > Ok, this is the simplified case from Weston. There is a pixel buffer > from a client (the window), a transformation that maps it to the output, > and the output framebuffer. The transformation can be an arbitrary 3x3 > matrix, but the most complicated thing we use so far is rotating the > window on the xy-plane by an arbitrary amount. > > We use the destination clipping on the framebuffer to avoid too much > useless compositing outside the source image (window). The clip > (pixman_region32_t) is essentially the intersection of the window's > boundingbox on the output and output damage we want to repaint. IOW, it > is an approximation. Currently we rely on sampling outside the source > image to produce (0,0,0,0) or skip compositing those pixels. > > This works fine as long as the whole pixel buffer from the client is to > be used. > > However, the client can use wl_viewport protocol interface to say, that > the compositor needs to use only a sub-rectangle of the pixel buffer. > If we don't have a complex transformation, we can transform the > rectangle to output space correctly and do all the clipping in output > space. > > If the transformation is complex, the rectangle in the client buffer > space is no longer axis-aligned in the output space, so we cannot > correctly transform it to output space. As we currently cannot do > clipping in source space, this use case is bugged. We composite areas of > the client buffer that should not be visible. > > So, we need to have axis-aligned rectangles (pixman_region32_t) in the > source image space doing clipping to cut away the unwanted parts. > > The underlying the problem is that we need an intersection between > axis-aligned and not-axis-aligned regions to compute the area we > actually want to paint. For instance, Weston's GL-renderer does this by > triangulating the intersection of every box vs. transformed box pair > between the two pixman_region32_t's. > > > In some cases, the source image clipping might be simulated by > > just wrapping a rectangular area of an existing image as a new > > pixman_image_t. And then using it as the source image in the > > compositing operation. > > That's an excellent idea! I will try that. > > Btw. I did already try using a mask image, but it seems the mask image > is also given in the destination space wrt. transformation. Is that > correct? > > > Thanks, > pq > _______________________________________________ > Pixman mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/pixman >
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
