4 ms·
> “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
by 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 agoWith 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 agoThat's not true at all
- ajuc 3y agoIterate 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 agoIs 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 agoThis 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.