On Fri, 2003-03-28 at 22:19, Petr Vandrovec wrote:
>
> Problem is in the new pixmap handling, especially
> pixbuf.output - so now instead of memcpy we
> call some function for copying each byte from
> font to temporary buffer. As you can see,
> "constant" portion of time, independent of
> color depth, increased by 1sec for unaccelerated
> and by 0.75sec for accelerated putcs.
> It is 5% to 25% slowdown (5% for 32bpp unaccelerated,
> 25% for 8bpp accelerated).
>
Actually, the slowdown is caused not just by the overhead of the
read/write methods, but also due to the extra work padding and aligning
the bitmaps according to requirements of the hardware. This was because
James wanted support for buffers located not just in system memory but
also graphics/dma memory.
The result is that unaccelerated imageblit will slow down while properly
written accelerated imageblit will experience some speed up (not much,
probably around 5%).
We can:
1. partially reverse the code so it behaves similarly to 2.5.63.
Support for writing to graphics/dma memory will go away.
2. split the code path: one will go to the '2.5.63' path, the other
will go to the '2.5.66' path, depending on the setting of info->pixmap.
3. keep the code as is
Personally, I prefer #1, but it's up to James/Geert.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:32 EST