Whats holding ~100% D GUI back?

[Ethan]

On Friday, 29 November 2019 at 02:42:28 UTC, Gregor Mückl wrote:
> They don't concern themselves with how the contents of these 
> quads came to be.

Amazing. Every word of what you just said is wrong.

What, you think stock Win32 widgets are rendered with CPU code 
with the Aero and later compositors?

You're treating custom user CPU rasterisation on pre-defined 
bounds as the entire rendering paradigm. And you can be assured 
that your code is reading to- and writing from- a quarantined 
section of memory that will be later composited by the layout 
engine.

If you're going to bring up examples, study WPF and UWP. Entirely 
GPU driven WIMP APIs.

But I guess we still need homework assignments.

1) What is a Z buffer?

2) What is a frustum? What does "orthographic" mean in relation 
to that?

3) Comparing the traditional and Aero+ desktop compositors, which 
one has the advantage with redraws of any kind? Why?

4) Why does ImGui's code get so complicated behind the scenes? 
And what advantage does this present to a programmer who wishes 
to use the API?

5) Using a single untextured quad and a pixel shader, how would 
you rasterise a curve?

(I've written UI libraries and 3D scene graphs in my career as a 
console engine programmer, so you're going to want to be *very* 
thorough if you attempt to answer all these.)

On Friday, 29 November 2019 at 08:45:30 UTC, Gregor Mückl wrote:
> GPUs are vector processors, typically 16 wide SIMD. The shaders 
> and compute kernels for then are written from a 
> single-"threaded" perspective, but this is converted to SIMD 
> qith one "thread" really being a single value in the 16 wide 
> register. This has all kinds of implications for things like 
> branching and memory accesses. Thus forum is not rhe place to 
> go into them.

No, please, continue. Let's see exactly how poorly you understand 
this.

On Friday, 29 November 2019 at 09:00:20 UTC, Gregor Mückl wrote:
> All of these things can be done on GPUs (most of it has), but I 
> highly  doubt that this would be that much faster. You need 
> lots of different shaders for these primitives and switching 
> state while rendering is expensive.

When did you last use a GPU API? 1999?

Top-end gaming engines can output near-photorealistic complex 
scenes at 60FPS. How many state changes do you think they perform 
in any given scene?

It's all dependent on API, driver, and even operating system. The 
WDDM introduced in Vista made breaking changes with XP, splitting 
a whole ton of the stuff that would traditionally be costly with 
a state change out of kernel space code and in to user space 
code. Modern APIs like DirectX 12, Vulkan, Metal etc go one step 
further and remove that responsibility from the driver and in to 
user code.

aberba wrote:
> Whats holding ~100% D GUI back?

A lack of skilled and knowledgeable people with the necessary 
time and money to do it correctly.