5 ms·

I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development. “Our memory is slow, s

by Aeolun 3y ago

I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development. “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays. Still the optimization in 4-6 is fun. Did the whole thing in 1-3 just because of an assumption that the buffer would not wrap around, and then it did and all that work became obsolete.

incrudible 3y ago
“Our memory is fast, so let us redraw everything” is a given. Our web APIs on the other hand are incredibly slow, so let us carefully track changes in a complicated runtime (or compiler) to avoid redundantly modifying properties in a tree.
II2II 3y ago
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).
- magicalhippo 3y ago
  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 https://learn.microsoft.com/en-us/windows/win32/gdi/clipping
- peterfirefly 3y ago
  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.
Sharlin 3y ago
Games have redrawn everything on every frame for decades, certainly since GPUs became a thing. Memory speed is definitely not a concern. 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well. On the other hand, of course, CPUs do have a complex system of several levels of caches, but that's not primarily because of (lack of) memory bandwidth but memory latency.
- badsectoracula 3y ago
  > 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well. For Win32 and X11 at least the damaged region (or "invalid region") approach is still there and AFAIK recently (as in a few months ago) the modesetting driver for Xorg added the ability to use the damage regions when "TearFree" is enabled (this does server-side composition to avoid tearing - it is disabled by default) to only update the of the screen that changed instead of the entire screen. Also i remember reading some time ago about some monitors being able to use partial frame data (the monitor "shadows" the frame) so that they can support faster updates. I think the concept can also help with slow display tech like e-ink devices.
- HWR_14 3y ago
  Games started redrawing everything because once you have a camera that rotates in 3D, the pixel reuse drops a lot vs one that pans over a 2D plane.
  - deleted 3y ago
    [deleted]
- esprehn 3y ago
  All modern web browsers still do tiling (at the compositing layer level). It's the only way to handle large layers and scrolling efficiently. Some also implement partial redraw into the tiles to handle things like cursors blinking to avoid having to redraw the entire tile.
- pjmlp 3y ago
dylan604 3y ago
>I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development. Yes, it's you and your vaulted position of standing on the shoulders of those to whom these developments actually were ‘revolutional’. I equate the level of accomplishments from Id to be at the level of cavemen throwing rocks at the spaceship to cavemen buying insurance on TV levels of achievement.
- x0x0 3y ago
  If you weren't playing games in early 1997 then Quake started using voodoo cards, it's nearly impossible to understate the before vs after. Carmack and id are responsible for at least 4 or 5, "I had no idea a computer could do that" moments for me.
fzeindl 3y ago
> “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays. Tangentially related: Android still doesn't get this. Turn on the screen refresh flashes in the developer menu and then look a your static screen and be amazed who often android draws even though nothing changed.
- ajuc 3y ago
  With modern gpu pipeline and cost of cache misses compared to CPU cycle being what they are - it's almost certainly faster to redraw a few thousand sprites no matter what than to check what changed and redraw only a subset of them. Energy efficiency is a separate matter.
  - djmips 3y ago
    That's not true at all
    - ajuc 3y ago
      Iterate over 1000 objects doing ifs and draw let's say 50 of them vs dump them in VBO and call glDrawArrays every frame drawing all 1000 of them? I'm willing to bet :) The difference in time spent by GPU between drawing 1000 and 50 sprites is almost 0.
  - dakom 3y ago
    Is there another way? I've only done WebGL, so not familiar with Vulkan/Metal/DirectX/etc. - but in my experience you're clearing the screen and re-drawing everything every tick no matter what. If only for applying post-processing effects. Updating buffers is of course a totally separate thing, and on that side I don't think anyone updates everything every tick, usually there's some sort of scene graph that knows about dirty transforms and their children, so only those get updated..
- izacus 3y ago
  This is nonsense, Android always did "this". It always rerendered only damaged regions and even after switching to HW accelerated rendering, it still only rerenders changed views. And the animation framework always just "scrolled" the view (or screen) when it could.
anthk 3y ago
Ncurses does the same on text, just redraw what it changes. Reason? Think about slow terminals or modems.
- ygra 3y ago
  When I developed a text-mode UI library (not using curses) with a friend in university for fun, we tested this on his actual terminal connected via serial cable. You'll notice unnecessary redraws very quickly that way. (Granted, piping the output through some throttling may have had the same effect, but there was something about writing modern code (even as students) and seeing it work on decades-old hardware :).)

by Aeolun 3y ago

incrudible 3y ago

“Our memory is fast, so let us redraw everything” is a given. Our web APIs on the other hand are incredibly slow, so let us carefully track changes in a complicated runtime (or compiler) to avoid redundantly modifying properties in a tree.

II2II 3y ago

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).

magicalhippo 3y ago
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 https://learn.microsoft.com/en-us/windows/win32/gdi/clipping
peterfirefly 3y ago
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.

Sharlin 3y ago

Games have redrawn everything on every frame for decades, certainly since GPUs became a thing. Memory speed is definitely not a concern. 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well. On the other hand, of course, CPUs do have a complex system of several levels of caches, but that's not primarily because of (lack of) memory bandwidth but memory latency.

badsectoracula 3y ago
> 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well. For Win32 and X11 at least the damaged region (or "invalid region") approach is still there and AFAIK recently (as in a few months ago) the modesetting driver for Xorg added the ability to use the damage regions when "TearFree" is enabled (this does server-side composition to avoid tearing - it is disabled by default) to only update the of the screen that changed instead of the entire screen. Also i remember reading some time ago about some monitors being able to use partial frame data (the monitor "shadows" the frame) so that they can support faster updates. I think the concept can also help with slow display tech like e-ink devices.
HWR_14 3y ago
Games started redrawing everything because once you have a camera that rotates in 3D, the pixel reuse drops a lot vs one that pans over a 2D plane.
- deleted 3y ago
  [deleted]
esprehn 3y ago
All modern web browsers still do tiling (at the compositing layer level). It's the only way to handle large layers and scrolling efficiently. Some also implement partial redraw into the tiles to handle things like cursors blinking to avoid having to redraw the entire tile.
pjmlp 3y ago

dylan604 3y ago

>I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development. Yes, it's you and your vaulted position of standing on the shoulders of those to whom these developments actually were ‘revolutional’. I equate the level of accomplishments from Id to be at the level of cavemen throwing rocks at the spaceship to cavemen buying insurance on TV levels of achievement.

x0x0 3y ago
If you weren't playing games in early 1997 then Quake started using voodoo cards, it's nearly impossible to understate the before vs after. Carmack and id are responsible for at least 4 or 5, "I had no idea a computer could do that" moments for me.

fzeindl 3y ago

> “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays. Tangentially related: Android still doesn't get this. Turn on the screen refresh flashes in the developer menu and then look a your static screen and be amazed who often android draws even though nothing changed.

ajuc 3y ago
With modern gpu pipeline and cost of cache misses compared to CPU cycle being what they are - it's almost certainly faster to redraw a few thousand sprites no matter what than to check what changed and redraw only a subset of them. Energy efficiency is a separate matter.
- djmips 3y ago
  That's not true at all
  - ajuc 3y ago
    Iterate over 1000 objects doing ifs and draw let's say 50 of them vs dump them in VBO and call glDrawArrays every frame drawing all 1000 of them? I'm willing to bet :) The difference in time spent by GPU between drawing 1000 and 50 sprites is almost 0.
- dakom 3y ago
  Is there another way? I've only done WebGL, so not familiar with Vulkan/Metal/DirectX/etc. - but in my experience you're clearing the screen and re-drawing everything every tick no matter what. If only for applying post-processing effects. Updating buffers is of course a totally separate thing, and on that side I don't think anyone updates everything every tick, usually there's some sort of scene graph that knows about dirty transforms and their children, so only those get updated..
izacus 3y ago
This is nonsense, Android always did "this". It always rerendered only damaged regions and even after switching to HW accelerated rendering, it still only rerenders changed views. And the animation framework always just "scrolled" the view (or screen) when it could.

anthk 3y ago

Ncurses does the same on text, just redraw what it changes. Reason? Think about slow terminals or modems.

ygra 3y ago
When I developed a text-mode UI library (not using curses) with a friend in university for fun, we tested this on his actual terminal connected via serial cable. You'll notice unnecessary redraws very quickly that way. (Granted, piping the output through some throttling may have had the same effect, but there was something about writing modern code (even as students) and seeing it work on decades-old hardware :).)