There's this odd pattern in some UXA code that appears to have been carried over from fbfillrect.c where for each thing to be filled we:
1) clip against the clip extents 2) trivial reject 3) clip that against each box of the clip 4) reject per box 5) draw. I don't see a justification for this complexity, in terms of how I expect cliprects to be (generally 1 rectangle) or in terms of how I expect rendering to be (generally within cliprects if there are any). And, we see from the history of uxa-accel.c, we've screwed up this clipping up before. So, I propose instead, we: 1) Clip against each box of the clip 2) Reject per box 3) draw. Here are the patches. No performance testing included, but one known bug is deleted (which I actually hope we land the small submitted fix for first, I'm just hoping to get a name/commit message on it). _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
