One thing I didn't see mentioned yet is that "screenshots" aren't always snapshots of the current frame, or captures of a "screen" at all.
You see, modern resolutions require huge amounts of pixel data to be transferred from the graphics processor (GPU) to the monitor many times a second. Both software and hardware have evolved to not transfer repeated information, so in particular the pixels rendered by the GPU are only sent to the monitor, not the CPU, unless requested.
One consequence of this is that for a screenshot, pixel data often has to be "reconstructed", and at the very least it has to be sent back from the GPU to the CPU, both of which can take considerable time from the moment you press the PrtScrn button.
Still, newer GPU's can often reconstruct and send back data from a recent frame to the CPU even under heavy load, but a consequence of this is that the screenshot may be slightly outdated. You'll notice this delay even more when you try to stream/record, it can be over a second on some hardware.
Once again, the reasons for this is an overflow of information; The millons of pixels on the GPU first has to be reconstructed/converted/compressed/whatever before it can be transferred to the CPU at a reasonable speed and in a format the CPU can understand.
Remember that both the CPU and GPU have to communicate and spend time waiting for each-other while doing this, and have to do other stuff in the meantime as well.
We're long gone from the age of sending pixel data directly to the monitor, or even having to worry about sending pixel data at all (software today is sending textures/models/triangles instead, which can convey the same picture with much less information). We are used to multiple/movable/overlappable/transparent windows, but there are actually many complicated systems that allow for this to happen, each of which might have their own way to obtain a "screenshot" with various level of detail. I know of at least 4 ways to obtain screenshots on my Linux machine, each of which has it's own benefits and drawbacks. And importantly, NONE of these methods actually guarantee they capture exactly what was displayed on the screen.
Some systems can screenshot normal windows without delay, but not games or when under high load, some systems may request screenshots from the GPU every frame, so you can get the perfect screenshot you want, even when what you were capturing was occluded, some can only "screenshot" windows one at a time, while others don't support real-time screenshots at all.
No system is the same, but the one thing every screenshotting mechanism has in common is that it has to worry about receiving 1920x1080 (or more!) pixels and converting them into an image file without locking up the entire computer. For that, compromises have to be made which camera's don't have to deal with.
1So is what you're saying as simple as "the operating system (potentially) has an api which provides functionality to get whatever is currently displaying on screen" and it's just a matter of working out what OS you're on, what apis are available, and then calling the corresponding function? – will – 2019-12-31T18:58:10.320
1@will Pretty much, though it's specifically the graphics system, which might be part of the OS (as in Windows), a managing program running on top of the OS (Windows 3, X, Wayland), or a single program handling all graphics (such as games both modern and ancient). – chrylis -on strike- – 2020-01-01T03:34:26.010
On Linux the OS itself has a graphics API or two (DRI, fbdev) which Xorg itself uses, and of course in an X11 environment you'd normally use the X11 APIs provided by Xorg, but technically you could also grab an image using the privileged DRI or fbdev APIs... On Windows, I actually have no idea where the boundary between OS kernel and graphics system is at all. – user1686 – 2020-01-01T11:00:37.853
@chrylis-onstrike- Thanks. I figured there would be modules/layers/whatever they're called that handle graphics, but didn't know how to describe that aspect of the system as a whole. And i would have guessed that there would be apis at multiple levels that would call the lower level apis of other systems (as (i believe?) open-gl does with the apis of the graphics cards). – will – 2020-01-03T18:41:36.293