No. It will update the screen for every character/newline printed. But stdout in C is line-buffered by default, so only full lines get sent to the console (if we are talking about userspace).
You are right, there is no optimization regarding the newlines (scrolling) like I've speculated. Every newline scrolls the output physically [1].
There is also apparently no extra buffering on the kernel side (i.e. aggregation of multiple write operations from user space), just the user space line buffering itself.
However, I believe there is at least a very modest optimization regarding the updates on the line [2]. If I understand the code correctly, the characters are not fed to the console driver one by one, but in chunks. This could be potentially used by the console driver to draw the glyphs of several characters more efficiently (or at the very least amortizes a few cycles on the function calls).
Anyway, thanks to this discussion we can be sure that Linux does not do any major magic here. Thus it should be straightforward to match it.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/vt/vt.c?h=v6.6#n2148 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/vt/vt.c?h=v6.6#n2566
If there is an inherent problem in updating a graphical console in Qemu, it should affect Linux graphical console too. Maybe you should try running a linux with graphical console in your Qemu and try to compare the results. If the problem does not occur with Linux, might be good idea to investigate exactly what the difference is.
Yes, I agree completely. Therefore I have provided the measurements of the performance of my Linux console. To have some sort of sensible baseline.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
