<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:8pt; font-weight:400; font-style:normal;">On piątek 19 czerwca 2009 18:40:48 Barry Scott wrote: > Łukasz Kuryło wrote: > > > > Or maybe after transformation to crtc coordinates, crtc->y is > > unnecesary? > > > We need someone that knows what crtc->y is used for to comment. > > > Then fixing the code to match will be simple. > > > > > > Barry > > > > > > I've updated my odg drawing. I'm thinking this should be good approach: > > > > > > box_in_crtc_coordinates = *box; > > if (crtc->transform_in_use) > > pixman_f_transform_bounds (&crtc->f_framebuffer_to_crtc, > > &box_in_crtc_coordinates); > > y1 = (box_in_crtc_coordinates.y1 <= 0) ? 0 : box_in_crtc_coordinates.y1; > > y2 = (box_in_crtc_coordinates.y2 <= crtc_last_scanline) ? > > box_in_crtc_coordinates.y2 : crtc_last_scanline; > > > > > > My assumption here is that after transformation to crtc space all > > coordinates of the box are relative to "upper left" corner of given > > crtc (if rotated 180 than it's lower right corner, etc.) anyway > > relative to first scanline. > > With this assumption box_in_crtc_coordinates.y1 can be negative. All > > thats left is that we need to now how many scanlines crt has. In > > normal case thats crtcbox.y2 - crtcbox.y1. > > But when rotation is added we need to calculate that in other way. Or > > maybe that information is available somewhere without calculation? > That's good to know what the crtc-y is for. > I agree it should not be used at all as the transformation will bring > the box > into the valid range of lines for the crtc. It will NOT! pixman_f_transform_bounds does NOT clip box to selected crt area. It return smallest box My only assumption was that after transformation all coordinates are relative to crtc origin (first pixel of first scanline). But I'm not sure of that. I need to dig more in code to see what kind of tranformations are handled by crtc->f_framebuffer_to_crtc. > > I do not think you need to defense about y1 or y2 being out of range. Thats exactly what was necessary for me to work on dualhead configuration with dead space. On other configurations regions are probably already clipped to crt area. > The transformation must always give you valid line numbers. In which case: > > box_in_crtc_coordinates = *box; > if (crtc->transform_in_use) > pixman_f_transform_bounds (&crtc->f_framebuffer_to_crtc, > &box_in_crtc_coordinates); > y1 = box_in_crtc_coordinates.y1 > y2 = box_in_crtc_coordinates.y2 > > is all that is needed. > > If this is correct the patch to DRI2 did not need its defensive code either. I don't agree as mentioned above. > > Of course adding asserts would enforce this API contract on the > transformation. > > Barry > > </body></html>