On 10/11/2026 21:09, Samuel Thibault wrote:
Michael Kelly, le mar. 10 nov. 2026 20:43:40 +0000, a ecrit:
2) Some how identify when Mach might lose total control of the frame buffer,
perhaps after any user process has made a request to 'mbinfo'. From that
point on, don't maintain the character backing buffer for printfs and do
scrolling by memmove of the frame buffer memory. This memmove method is
extremely slow with something like 2 scrolls per second on my hardware
machine. With my frame buffer code, this is perhaps nearer 50 scrolls per
second and I'm certain it's far from optimal. This performance increase is
because with the character backing buffer there are no reads to the video
memory and only writes.
I'm not sure to understand. Do you mean that reads from video memory are
*extremely* slow? i.e. that we are fine with writing the whole console,
but reading it to re-write it with a vertical offset, is awfully slow?
That is *very* surprising. I mean, even if video memory is on a
separate video card, the PCI bus is not that slow, a 1600x1200x32bpp
framebuffer is 7MB, by nowadays' bandwidth standards that should be just
a millisecond to read.
I initially took the code from just the fast case of bmpmvup
(i386/i386at/kd.c) which all that is needed to support output scrolling.
The asm kd_slmscu is a simple memmove, but I actually used memmove later
without any obvious difference. The reimplementation to redraw all the
characters was so much faster. It was my conclusion therefore that the
read was much slower than the write but this has not been verified directly.
Perhaps it might be comparably faster to read the entire frame buffer to
somewhere temporary, adjust and rewrite it back, like a kind of
ephemeral backing buffer?
Your being so surprised makes me wonder if there is something else
happening. Perhaps I should write some code that times reads and writes
of the frame buffer to provide more certainty.
Thanks for your input,
Mike.
