| > 90s apps used these Windows handle controls and it was not a performance problem. That depends on the overhead per window. Microsoft Windows could use nested windows because it had separate Graphics objects to store such things as the current drawing pen, its position and the current font to use for drawing (https://learn.microsoft.com/en-us/windows/win32/api/gdiplusg...) In comparison, on the classic Mac every window had a GrafPort that defined a boundary region, a clipping region, the current pen position, size, drawing pattern, etc. The Mac could have such heavy-weight window objects because it didn’t nest windows. Instead, each window had a single list of controls that were much lighter-weight. my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. (its documentation is ‘less than stellar’, but it appears GrafPort still exists: https://developer.apple.com/documentation/applicationservice...) |
GrafPort is part of QuickDraw, almost all of which was removed in 64-bit macOS. (A handful of QuickDraw functions survive, but they can't actually be used to do drawing, just to manipulate Point/Region/etc data structures.)
From what I understand, this struct/typedef remains in the headers to help with compiling legacy code–but all the APIs which take it as an argument have been removed, so it is essentially a useless vestige.