It's the sort of optimization that one can read about in games and DirectX programming books.

A better optimization comes with the realization, as MacOS people had many years ago, that copying from system memory to video memory is slow. So one instead pre-loads the glyphs into off-screen video memory, possibly on-demand, and then uses the display hardware to blit them into the on-screen part.

Of course, this requires that code know about blitter hardware, which does not necessarily exist. If one is doing an in-kernel terminal emulator, such as wscons in OpenBSD here, then one can rely upon the fact that the EFI Graphics Output Protocol provides a Blt() function that is supposed to abstract away the hardware. Indeed, EFI GOP can in theory not provide direct framebuffer access in the first place and require that everything be blitted (PixelBltOnly).

We who write application-mode terminal emulators are not so fortunate. (-:

GOP functions aren't available after ExitBootServices() has been called, so the kernel doesn't get to take advantage of Blit() - the assumption is that the kernel will have a native driver for the hardware. Additionally, you can't really use off-screen graphics RAM in the EFI environment because GOP doesn't tell you how much video RAM is actually available, only the size of the framebuffer. You can guess which PCI device is associated with the framebuffer and look at the size of the BAR, but you have no way of knowing which addresses the EFI driver is using for its own purposes. Apple have enough control over their platform that they could possibly make this work, but it's tough when you're dealing with a vendor-provided driver on an add-in card.

Hah! I've been doing too much load-time stuff, obviously. (-:

But if one is looking at PCI device IDs, then one is already at the level of the code having detailed knowledge of the specific hardware (even if only via some "miniport"-like system) and the point stands.

Oh, you can look at the device that the GOP instance is bound to and get the PCI device from there. At that point you just walk the BARs looking for one that's mapped in a region that covers the framebuffer address that GOP gives you. This doesn't require you to know anything about the device in question, and most of the time you'd probably get lucky by throwing glyphs in space that exists outside the framebuffer and blitting them onto the screen - up until you find a driver that implements blt() by using the 3D engine and mapping some buffer objects on top of the space you're trying to use.

The code will still have to know about blitter hardware, as I said.

Any design that depends from "you'd probably get lucky" is not a wise one. (-: