3 ms·
Might have been technical limitations. When you allow overlap, you can’t use the screen as _the_ backing store for pixels anymore, and either memory usage goes
by Someone 5y ago
Might have been technical limitations. When you allow overlap, you can’t use the screen as _the_ backing store for pixels anymore, and either memory usage goes up (a lot, if you’ve several large windows open), or you have to invent redraw events (which may be slow even for relatively simple content, if you have to swap in the drawing code).
If you keep the screen buffer as (part of) the backing store for the pixels of windows, you also have to make drawing code clip to any overlapping windows. If you don’t, memory usage goes up again.
And memory could be tight. As an extreme example, the screen memory on an original Mac was about the same size as the amount of memory available to the running application.
- ncmncm 5y agoFor reference, the original Mac was 512x342, monochrome: 21,888 bytes. It had 128K RAM total, including that. It was essential for programs to rely on code in the ROM so as not to waste precious RAM. Running your program and also the "Finder" (desktop) at the same time was novel. It did overlapping windows, and the program was expected to re-draw the part exposed if you moved one. The 512k version, or "Fat Mac" came out soon after, and was actually useful.