Michael Kelly, le mar. 10 nov. 2026 21:32:55 +0000, a ecrit:
> 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.
Ok.
> 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?
At least it's probably faster to read sequentially in the memory order
rather than glyph per glyph.
> Your being so surprised makes me wonder if there is something else
> happening.
Possibly the video memory is really not made for reading and thus very
slow.
Actually, I'm thinking: making gnumach just redraw its characters should
be fine. Actually that might be better, so that it is just drawn over
the application content, without completely filling the screen but
something like:
done____________________________________________________________________________
scsi : 0 hosts._________________________________________________________________
scsi : detected total.__________________________________________________________
Partition check (DOS partitions):_______________________________________________
sd0: sd0s1 sd0s2_______________________________________________________________
sd1: unknown partition table___________________________________________________
sd2: unknown partition table___________________________________________________
sd3: unknown partition table___________________________________________________
com 2 out of range______________________________________________________________
lpr0: at atbus0, port = 378x, spl = 6d, pic = 7.________________________________
RTC time is 2026-11-09 17:34:43_________________________________________________
module 0: pci-arbiter --host-priv-port=${host-port} --device-master-port=${devic
e-port} --next-task=${acpi-task} $(pci-task=task-create) $(task-resume)_________
module 1: acpi --next-task=${disk-task} $(acpi-task=task-create)________________
module 2: rumpdisk --next-task=${fs-task} $(disk-task=task-create)______________
module 3: ext2fs --readonly --multiboot-command-line=${kernel-command-line} --ex
ec-server-task=${exec-task} -T typed ${root} $(fs-task=task-create)_____________
module 4: exec /hurd/exec $(exec-task=task-create)______________________________
5 multiboot modules_____________________________________________________________
task loaded: pci-arbiter --host-priv-port=1 --device-master-port=2 --next-task=3
task loaded: acpi --next-task=1_________________________________________________
task loaded: rumpdisk --next-task=1_____________________________________________
task loaded: ext2fs --readonly --multiboot-command-line=root=device:sd1 console=
com0 --exec-server-task=1 -T typed device:sd1___________________________________
task loaded: exec /hurd/exec____________________________________________________
where _ is the application content, which is fine not to scroll
actually, it's only the gnumach text that needs to scroll.
Samuel
