When you resized a window on classic Mac OS, your program had to actually like, draw the new window. Your program is spinning in a loop listening for events, you get a window-resize event. So you allocate space for the new bitmap, calculate what you need to display within the enlarged view, and then draw it. Did the user drag another window over your window, and then drag it away again? You get an event for that. Gotta draw what was there all over again.
This is all very close to the metal. On early 68K Macs, this is driven by QuickDraw, some very tightly coded assembly routines in ROM. Invoking them is only 2 bytes of code, as they're simply CPU opcodes (trap instructions). Render this string at this point size with this font at this X, Y location. Redraw the menu bar. Draw a rectangle. And so on. If you sequence these Toolbox invocations correctly, as a great master programmer of coroutines who never mistreats a handle as a pointer, you can render a complex scene with hundreds of polygons and a full screen of text in 200 milliseconds at 8 MHz.
But it takes thousands of lines of hand-holding the machine to do it.
Today, all of this is typically handled by instantiating a window object which draws into a private framebuffer which the system composites. That right there is tens of megabytes of RAM overhead. Then you use a thread to handle the UI and a thread to draw and etc. There's almost no boilerplate to just show a window. Perhaps one line of code. And it doesn't get overwritten by intrusive neighbour windows. Creating frameworks that can do all that bookkeeping in a flexible and general way (don't forget you want to be able to render vector fonts for any Unicode language) has a tremendous overhead.
This is all very close to the metal. On early 68K Macs, this is driven by QuickDraw, some very tightly coded assembly routines in ROM. Invoking them is only 2 bytes of code, as they're simply CPU opcodes (trap instructions). Render this string at this point size with this font at this X, Y location. Redraw the menu bar. Draw a rectangle. And so on. If you sequence these Toolbox invocations correctly, as a great master programmer of coroutines who never mistreats a handle as a pointer, you can render a complex scene with hundreds of polygons and a full screen of text in 200 milliseconds at 8 MHz.
But it takes thousands of lines of hand-holding the machine to do it.
Today, all of this is typically handled by instantiating a window object which draws into a private framebuffer which the system composites. That right there is tens of megabytes of RAM overhead. Then you use a thread to handle the UI and a thread to draw and etc. There's almost no boilerplate to just show a window. Perhaps one line of code. And it doesn't get overwritten by intrusive neighbour windows. Creating frameworks that can do all that bookkeeping in a flexible and general way (don't forget you want to be able to render vector fonts for any Unicode language) has a tremendous overhead.