Display / imaging as a "big data" problem[0] is turtles all the way down. If we separate "creating something to display" and "displaying something" and call tha

Display / imaging as a "big data" problem[0] is turtles all the way down. If we separate "creating something to display" and "displaying something" and call that the "display processor divide" and then ask "what passes across the divide?" in terms of information density then we see that it ebbs and flows. Suppose I say "print a line". Some program creates a line to my specifications, a driver[1] converts that into something to be shipped across the display processor divide, the display device (printer, monitor, [2]) runs the program.... oops, excuse me "print job". Sometimes the instruction granularity is something like "print a line", other times it's a bitmap, sometimes it's some of both ("print dot at"). Once upon a time "vector displays" expected "dot at" semantics, and "raster displays" did lines and fills; bear in mind, this was mostly done in hardware. An 8.5 x 11 inch piece of paper at 300dpi is 8415000 bits (33,660,000 at 600 dpi); at 30 frames a second it's 252,450,000. That's black and white. If you do 256 color, then 2Gbps. You (still) might need to throw hardware at that problem. Or throw software at the problem (compress it) so you can get by with the existing hardware. One final note: you won't be able to save that 250MB file and later print it out on something which doesn't exactly match the shape and density of the original device[3]. On the other hand an intermediate representation, like scalable vector graphics, or Postscript, allows different devices to be targeted but the ownership of that final conversion and where it should live depends. It depends on the "big data" nature of the problem in terms of what the final device is capable of (is it capable of running a Postscript interpreter), and who wants to pay to license the Postscript interpreter (don't forget about that!); and don't forget about firmware / driver updates. By the way, the intermediate representation is likely smaller; you can always compress that to feel good about yourself. The opacity is because the shear forces require everybody writing for one of these interfaces to take at interface value that what the other side sends / expects is blessed by the standards gods. Everybody feels like a Christian Scientist with appendicitis. I think you've got this backwards, you state "...moving the processing from the computer to the printer had a reasonable rationale" as fact, but what I've observed over the past 40 years has been a tendency to favor sending bitmaps across the divide, even when the display device (printer specifically, I'm talking about buying printers at Office Depot here) supports a higher level of abstraction. I am more than pleasantly surprised that my Canon G3270 is supported on reasonably modern SuSE Linux with a PPD (for printing, haven't bothered with the scanner). Mental exercise: suppose you had enough printers to dedicate one per pixel. Would you decompose the job and send every printer individualized instructions, or would you send the printer a program to allow it to pick its designated pixel out of the broadcast plan? [0] Big Data: when it gets too expensive to keep scaling what you're doing in a presumably integrated fashion, so you optimize by smacking the problem upside the head with dedicated hardware for one or more aspects and pave over the problems with software. [1] or... a compiler. [2] drone swarm? [3] emulating turtles