On N, 2010-07-08 at 13:45 +0300, Jonathan Morton wrote: > On Thu, 2010-07-08 at 17:17 +0800, Huang, FrankR wrote: > > Have a question for render operation on rotation. > > > I fixed the bug in lx_do_composite in geode driver. srcX and > > srcY are same as maskX and maskY. When I calculate the renderging > > region, I need to use "maskWidth - maskX" and "maskHeight - maskY" if > > Mask is not zero. > > > Same way, when the Mask in zero, we need do "srcWidth - srcX" > > and "srcHeight - srcY". But seems it is not reasonable for rotation in > > this way. When it is rotation, right now I am still use srcWidth and > > srcHeight. Is it any special for rotation? > > What kind of rotation is involved here?
We support only right-hand 90, 180 and 270 degree rotation indeed in geode - that's what the GPU can handle with some acceleration. We swap and shift the source or mask coordinates/width/height already at the start of our Composite vfunction http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_exa.c#n969 So to me the first question is if we need to do the same to maskX and maskY then before subtracting from maskWidth/maskHeight (which are currently confusingly actually srcWidth/srcHeight in the code - the variable is shared and goes for the mask if pMsk is set), as we have done the rotation adjustment to maskWidth/maskHeight already, but not maskX/maskY. Haven't spent much time on thinking about it yet though, so might be able to figure that part out myself too after some time. > AFAIK, XRandR will automatically apply an appropriate transform to > operations if a rotated framebuffer scanout is not available. So the > situation probably depends on that. I'm still somewhat confused about full screen rotation (xrandr --output default --rotate right) and individual rotating transforms on Composite operations. What operations do you refer to exactly that XRandR will automatically apply transforms on? > With alternate framebuffer scanout support, you would treat the > framebuffer as a normal unrotated pixmap with different dimensions (swap > width and height). Is this alternate framebuffer commonly referred to as "shadow framebuffer"? > Without it, XRandR will cause EXA to provide operations with 90-degree > rotate/translate transforms set on the source and mask images, and with > the (X,Y) and (width,height) pairs of the destination area swapped. In > this case you would need to understand how transforms work, although it > is unlikely that you would support anything but this specific 90-degree > case. Does this mean that with shadow buffer made, we will rarely get rotation transform operations in Composite? Only if libXrender clients explicitly ask, even if that? Regards, Mart Raudsepp _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
