Re: fbdev: Garbage collect fbdev scrolling acceleration

[Sven Schnelle <svens@stackframe.org>]

Hi Daniel,

Daniel Vetter <daniel@ffwll.ch> writes:

> On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote:
>> Helge Deller <deller@gmx.de> writes:
>> > Maybe on fast new x86 boxes the performance difference isn't huge,
>> > but for all old systems, or when emulated in qemu, this makes
>> > a big difference.
>> >
>> > Helge
>> 
>> I second that. For most people, the framebuffer isn't important as
>> they're mostly interested in getting to X11/wayland as fast as possible.
>> But for systems like servers without X11 it's nice to have a fast
>> console.
>
> Fast console howto:
> - shadow buffer in cached memory
> - timer based upload of changed areas to the real framebuffer
>
> This one is actually fast, instead of trying to use hw bltcopy and having
> the most terrible fallback path if that's gone. Yes drm fbdev helpers has
> this (but not enabled on most drivers because very, very few people care).

Hmm.... Take my Laptop with a 4k (3180x2160) screen as an example:

Lets say on average the half of every line is filled with text.

So 3840/2*2160 pixels that change = 4147200 pixels. Every pixel takes 4
bytes = 16,588800 bytes per timer interrupt. In another Mail updating on
vsync was mentioned, so multiply that by 60 and get ~927MB. And even if
you only update the screen ony 4 times per second, that would be ~64MB
of data. I'm likely missing something here.