Daniel Kurtz <djkurtz@...> writes: > Unfortunately, the calculation to determine if source and destination > lines overlapped was incorrect: > (1) it converts width from pixels to bytes, but width is actually in > bits, not pixels. > (2) it adds this byte offset to dst/srcLine, which implicitly converts > the offset from bytes to sizeof(FbBits). > > So, "careful" was true if the destination line was within 699392 bytes, > instead of just within its 1366 * 4 = 5464 byte row. > > This bug causes us to take the slow path for large non-overlapping rows > that are "close" in memory. As a data point, XGetImage(1366x768) on my > ARM chromebook was taking ~140 ms, but with this fixed, it now takes > about 60 ms.
I'm glad this got fixed now. It was noticed back in 2011 [1], but maybe a bit more persistence on my part would have saved countless Watt hours. [1] http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/23346 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
