>> Probably the lack of hardware area copies has something to do with
>> this. However, who isn't familiar with xterm "jump scroll" mode?
>> That's nice and fast.
>>
>> Could such a thing be implemented in the console driver?
>
>I believe so. It would be simple: if there's too much activit, defer
>framebuffer updates and only update in-memory copy. Sync from time to
>time. I'd certainly like to see that.
If the time between syncs gets to big then the amount of data to go over
the bus would kill performance. Plus this has the problem that even
small areas like 12x20 areas become more expensive as the bpp increases. A
better solution is to implement accelerated copyareas. In fact for 2.5.X I
have the fbcon system wrapped around using accels instead of writing to the
framebuffer directly. I have had enormous improvements doing this. Plus
using this approach makes the fbcon layer much simpler and smaller in size.
Thus better performace overall.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
-
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 : Sat Mar 31 2001 - 21:00:24 EST