Re:Commander Keen's Adaptive Tile Scrolling
by II2II on Thursday July 27, 2023 @08:22PM
(#36901827)
If I recall correctly, the original Macintosh would go as far as telling the software which regions of a window had to be redrawn at any given time so the idea itself wasn't exactly new. The thing is that these optimizations required tradeoffs. Figuring out which tiles had to be updated required storing extra data and doing extra computations. Not only did you have to recognize the value of these techniques, you actually had to write the code in a way that did not slow things down (and design the levels so they would not slow things down).
[ Parent
| on HN ]
Re:Commander Keen's Adaptive Tile Scrolling
by magicalhippo on Thursday July 27, 2023 @09:11PM
(#36902082)
Windows has had this[1] for as long as I remember as well, at least since Windows 3 days so I assume since the very beginning.
[1]: https://learn.microsoft.com/en-us/windows/win32/gdi/clipping
Re:Commander Keen's Adaptive Tile Scrolling
by peterfirefly on Friday July 28, 2023 @09:58AM
(#36906863)
They needed the same info to do clipping (on both the Mac and Windows).
I think it is more interesting that the pipeline was invalidaterect/region => getevent => event was a draw event => draw region (or part of it). The getevent would only generate draw events if nothing more important was going (keyboard/mouse input, timer, message from other app/desktop accessory). It would also prioritize top windows first so you would only get a draw event for a window at the bottom once the windows above had no more dirty areas.
If you really knew what you were doing, you could short circuit this a bit and draw in your windows outside of draw event handling.