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.

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

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.

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.

More like after shaders became a thing, and it hardly matters when it is an application runnning on the GPU that is responsible for actually drawing.

However it is still an issue if one wants to achive maximum performance, and it is done by only sending the vertices and textures to the GPU that are actually going to be visible.

Some modern game UI still use dirty draw tech.

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

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

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.

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

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

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.

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

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.

That's not true at all

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.

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

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.

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

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