Whats holding ~100% D GUI back?

Gregor Mückl gregormueckl at gmx.de
Sat Nov 30 15:42:16 UTC 2019


On Saturday, 30 November 2019 at 10:12:42 UTC, Ethan wrote:
> 4 entirely misses the point. Entirely. ImGui retains state 
> behind the scenes, and *then* decides how best to batch that up 
> for rendering. The advantage for using the API is that you 
> don't need to keep state yourself, and zero data is required 
> from disk to layout your UI.
>

I described the actual Vulkan implementation of ImGUI rendering 
based on the its source code. And it does exactly what you just 
said: batching! I even included reasons for why it does what it 
does the way it does. It's straightforward. Go check the code 
yourself if you don't believe me.

> 5, pathetic. The thorough answer is "determine the distance of 
> your output pixel from the line and emit a colour accordingly." 
> Which, consequently, is exactly how you'd handle filling 
> regions, your line will have a direction from which you can 
> derive a positive and negative space from. No specific curve 
> was asked for. But especially rich is that the article you 
> linked provides an example of how to render text on the GPU.
>
> (Anyone actually reading: You'd use this methodology these days 
> to build a distance field atlas of glyphs that you'd use to 
> then render strings of text. Any game you see with fantastic 
> quality text these days uses this. Its applications in the 
> desktop space is that you don't necessarily need to re-render 
> your glyph atlas for zooming text or different font sizes. But 
> as others point out: Each operating system has its own text 
> rendering engine that gives distinctive output even with the 
> same typefaces, so while you could homebrew it like this you'd 
> ideally want to let the OS render your text and carry on from 
> there.)
>

I didn't point anybody to distance field based text rendering 
because it doesn't handle a few things that desktop graphics care 
about. The main things are font hinting (which depends on font 
size in relation to screen resolution, so glyphs change *shape* 
when scaling under hinting to retain readability) and text 
shaping, so that text glyphs change shape depending on the 
neighboring glyphs. Text shaping is mandatory for Arabic script, 
for example. Also, distance field based text rendering is prone 
to artifacts under magnification: texture interpolation on the 
distance field texture causes sharp edges to be rounded off 
(that's even described in the original Valve paper!).

I'll stop this discussion with you here, Ethan. This is becoming 
unhealthy. We need to take a step back from this.



More information about the Digitalmars-d mailing list