D GUI Framework (responsive grid teaser)

[Ola Fosheim Grøstad]

On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote:
> On 2019-05-22 17:01:39 +0000, Manu said:
>> I mean, there are video games that render a complete screen 
>> full of zillions of high-detail things every frame!
>
> Show me a game that renders this with a CPU only approach into 
> a memory buffer, no GPU allowed. Total different use-case.

I wrote a very flexible generic scanline prototype renderer in 
the 90s that rendered 1024x768 using 11 bits each for red and 
green and 10 for blue and hardcoded alpha blending. It provided 
interactive framerates on the lower end for a large number of 
circular objects covering the screen, but it took almost all the 
CPU. It even used callbacks for flexibility and X-Windows with 
shared-memory, so it was written for flexibility, not very high 
performance.

Today this very simple renderer would probably run at 400-4000FPS 
on the CPU rendering to RAM.

So, it isn't difficult to write a decent performance scanline 
renderer today. You just have to think a lot about the specifics 
of the CPU pipeline and CPU caching. That's all. A tile based one 
is more work, but will easily perform way beyond any requirement.

I'm not saying you should do it. It would be CPU specific and 
seems like a waste of time, but the basics are really very 
simple. Just use a very fast bin sort for the left and right edge 
in the x-direction, then use a sorting algorithm that is fast for 
almost-sorted-lists for the z-direction (to handle alpha 
blending).

Basically brute force, no fancy datastructure. Brute force can 
perform decently if you use algorithms that tend to be linear on 
average.