Timeline for Was 1991's Hellcats the first instance of incremental screen updates?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2018 at 21:13 | comment | added | supercat | @MichaelShopsin: I programmed classic Macintosh back in the day, so I'm familiar with the way the VisibleRegion, ClipRegion, and UpdateRegion interacted. Drawing was done on the intersection of VisibleRegion and ClipRegion, Actions which augmented VisibleRegion would do UpdateRegion |= (newVisibleRegion & ~oldVisibleRegion), and there was a pair of begin-update/end-update function, the first of which would IIRC save visible region, compute VisibleRegion &= UpdateRegion; UpdateRegion = empty, and the latter of which would restore VisibleRegion. | |
| Oct 25, 2018 at 20:56 | comment | added | Michael Shopsin | @supercat PARC could only update rectangles, but they did a good demo for Apple's engineers so they thought that regions were a solved problem. Bill Atkinson then wrote the regions code used in the Lisa and MacOS assuming that it had to work. | |
| Oct 25, 2018 at 18:50 | comment | added | Maury Markowitz | I'm not familiar with Windows, but i am fairly familiar with the Mac side and their update "regions" are not the same thing. Regions worked the other way, any draw indicated what regions were updated, in Hellcats it was the other way around, draws did NOT indicate what changed, you had to do post-draw comparisons to know. | |
| Oct 25, 2018 at 15:41 | comment | added | supercat | @MichaelShopsin: I wonder whether the PARC system used anything similar to regions? The approach of being able to process intersecting regions so as to produce a single description of the area of the screen that should be affected by drawing operations is a vast simplification compared with having to examine a data structure containing all overlapping windows. | |
| Oct 25, 2018 at 14:35 | comment | added | Michael Shopsin | Classic MacOS used regions for updated, the clever part was that regions did not have to be rectangular or contiguous so the absolute minimum number of pixels would be redrawn. See Folklore.org for a long article about regions. | |
| Oct 24, 2018 at 21:50 | comment | added | snips-n-snails |
You have to explicitly create a MemDC if you want to double buffer. With or without the MemDC, there's no need to redraw the whole window, just paint the background of the region specified by the WM_PAINT message, then iterate through your controls, check which ones coincide with the region that needs to be repainted (in MFC, use CRect::IntersectRect()), and repaint just those controls. This may or may not be faster than double buffering but for sure it uses less memory.
|
|
| Oct 24, 2018 at 21:26 | comment | added | tofro | @traal I didn't say that. A MemDC is double buffering in my book. You can obviously not make use of the offering the GUI makes to you and redraw the whole screen from scratch with every WM_PAINT. | |
| Oct 24, 2018 at 21:20 | comment | added | snips-n-snails | WM_PAINT doesn't require double buffering. An application may either create a memory device context (MemDC), write to that, then copy the contents to the main DC, or the application can bypass the memory DC and write directly to the main DC. | |
| Oct 24, 2018 at 16:10 | history | edited | tofro | CC BY-SA 4.0 |
added 577 characters in body
|
| Oct 24, 2018 at 16:02 | history | answered | tofro | CC BY-SA 4.0 |