(CC'ed the mailing list, I hope you don't mind)

On Thu, 20 Jun 2024 at 19:30, Nino Stephen wrote:
> I'm not a developer by profession, so GUI frameworks and how they work under-the-hood wasn't something that came under my radar. Looking at Gio's source code was really helpful. That along with some blogs did help me get a vague idea about the working of frameworks like Gio.
>
> However, my understanding is on an extremely high-level and the whole thing feels like magic. This is mainly because my batch in college never got to learn graphics programing. As a curious person who likes to understand how things work, I would like to learn more about how Gio works under-the-hood.
>
> If you don't mind me asking, could you share links to resources I could refer? My aim is to build a really basic and barebone version of Gio from the ground up. I'm aiming to create 3 things, namely a window, a label and a button. That too on Linux.
>
> I'm more than happy to read as much documentation as possible to build it. Any resources you could share would be really helpful.
>

Hi Nino,

In my Gio-biased perspective, a GUI library or framework must address 4 topics

- State management
- Layout
- Input handling
- Drawing/rendering

Perhaps surprisingly, I consider rendering (what I believe you call
graphics) the least important
because few users end up using your graphics API directly. On the
other hand, graphics are
also the hardest to implement: users expect real-time, dynamic,
complex vector graphics on high
DPI screens even on slow mobile devices.

See

https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harder-than-3d-graphics/
https://mattdesl.svbtle.com/drawing-lines-is-hard

for some of the issues. Also

https://raphlinus.github.io/rust/graphics/gpu/2019/05/08/modern-2d.html
https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fast-2d-rendering.html

for state of the art perspectives on how to improve rendering of
vector graphics on the GPU.

Gio's renderer is based on an earlier version of
https://github.com/servo/pathfinder, which is
reasonable but not great in terms of performance, flexibility and
rendering quality.

On top of all that, GPU APIs are frustratingly fragmented (OpenGL,
Vulkan, Direct3D, Metal)
and full of buggy or slow or old device drivers, and you'll be
handicapped (like Gio) without a
performant CPU fallback for platforms where a GPU is not available for
some reason.

Because of the above issues, I'm investigating whether the vector
graphics primitives
(curves, fill, strokes) are the best fit for GUIs in general, Gio in
particular. This is just to say
that vector primitives may not even be the best choice for your GUI library.


That leaves the interesting parts: state management, input handling,
layout. Interesting in the
sense that those are what the user mostly interacts with when writing
GUI programs with your library.
There are many ways to design a GUI library, and I'm sure you know
that Gio provides just one
way, the so-called "immediate mode" design. The main idea in immediate
mode designs
is to avoid issues with state management and input event callbacks by
always re-generating a
full frame for every update, similar to how video games are architected.

I wrote a bit about immediate mode here,

https://eliasnaur.com/blog/immediate-mode-gui-programming

but I got the main ideas from Casey Muratori's older post,

https://caseymuratori.com/blog_0001

As you probably also know, there exist a bunch of other approaches
with their own
trade-offs: react, retained mode etc. I'm no expert in these so I'll
let others come up with
good references for these alternatives.

Thanks,
Elias