On Mon, Feb 9, 2009 at 6:01 PM, Mark van Doesburg
The current code works breaking the overlapping region down into regions the size of the non-overlapping part and copying them over one by one. That way you never have to worry about raster direction since you are always copying a non-overlapping part.
That's what the code said, I just didn't want to believe that was actually happening. So dragging a 1000x1000 window by one pixel diagionally results in a 1000000 operations, no wonder my Matrox G400 felt faster. (And the cpu load reaches 95% when dragging a window)
if you move it one pixel, but more often than not, the region is bigger than one pixel.
Those primitives were designed for that purpose, but they don't work like the other primitives. The VGT and vertex setup setup is completely different. They were implemented for the 2D emulation in the CP microcode on r6xx chips. They aren't really supposed to be usable by software according to the hw folks.
Alex
So there was supposed to be a better solution, but it doesn't work, too bad. Sorry for wasting your time, I guess I'll have to wait until the rest of the documenation is available.
Thanks for the info (and the driver of course).
That solution works if you use the CP 2D emulation, but it's only available on r6xx chips so we can't use it for r7xx. With more and more movement towards composited desktops this becomes less of a issue. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org