Whats holding ~100% D GUI back?
Ethan
gooberman at gmail.com
Fri Nov 29 10:08:59 UTC 2019
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.
More information about the Digitalmars-d
mailing list