@zirias Looks good to me, with just a quick cursive glance over the code.

I'll wait to see how you get on, but there's a couple of things around handling replies from xcb which you could probably add. I'm sure you've noticed this already, but the pattern of:

xcb *cooke_reply = xcb_api_call();
if (cookie_reply == NULL) {
/* Some error. */
}

Is a common pattern. It can get a bit annoying...

@zirias Heh. Don't put too much faith in my (rather tired) eyes, but you're welcome.

Yeah -- you should be fine to collate a bunch of cookie-replies together -- XCB is designed to send them whenever, so it's up to you to process them when you see fit -- which is non-blocking my design.

Interestingly, most of the "older" XLib APIs use XCB under-the-hood, so whichever way you look at it, XCB is used all over the place.

@thomasadam Yes, I read it was more or less rewritten on top of xcb as "xlib-xcb", which eventually replaced the old xlib completely. Diving into #X11 now, starting at the "lowest level" (without trying to implement the protocol yourself) seemed appropriate 😉

The only "issue" I have is lack of documentation ... there are *some* (incomplete) manpages, there are doxygen-docs (found online or you can directly read the installed headers) which is also incomplete and *very* brief ... and then you can of course use google and hope for the one actually *helpful* stackoverflow result 🙈😄

At least there's a tutorial somewhere explaining the basics.

@thomasadam Well, seems this would have been rushing it, font rendering only after getting a sane base for windows and widgets 🤔

For now, I added a base "Object" for classes that need inheritance with virtual functions (guess that's hard to avoid in GUI code when you want a somewhat "clean" model) and some very basic "Window" base class with a few properties.

This will be a slow project 😅

Ok, handling #xcb replies completely #async from a "cookie queue" (actually only the #X11 sequence number is relevant) *seems* to work. But only tested with very simple cases so far that don't have a reply 🙈

BTW, that's certainly one of the heavily underdocumented areas of xcb 🙄

https://github.com/Zirias/xmoji/commit/c6d5e8f754437f0cd39dc52fe3651e89052bfcc4

Hehe, my "plain #X11 with #xcb" journey is really starting at square 1.

TIL, "legacy" (ICCCM) X11 window properties use a type STRING which only allows #latin1 encoding. There's a weird thing called COMPOUND_TEXT to work around that which probably isn't worth implementing today. 🤯

Fixed my code to
- Make sure we use a UTF-8 locale
- Convert the window title to Latin1 for setting WM_NAME
- Additionally set the original UTF-8 title in _NET_WM_NAME (of type UTF8_STRING).

Wow, baby steps 😂

https://github.com/Zirias/xmoji/commit/3701d56cc76e1cd5688e20aed3539562faf90950

Next baby step exploring #X11 with #xcb ....

after setting some sane WM_CLASS on my window, my #fvwm3 config doesn't mistakenly set it slightly transparent any more 🙈

https://github.com/Zirias/xmoji/commit/33f575fba110a9b0fc830b41a34f744b67c58149

Ok, after experimenting a bit with #fontconfig, seems it has a lot of "helpful" magic to "always give you *some* font". Nice, but that could be whatever. To allow an application-side priority list, I hacked comparing at least the family name of the suggested match, but as a very last resort, just request "sans" and take whatever you get 🙈

https://github.com/Zirias/xmoji/blob/8b502a8e0ebc549da9ac3cc71b46fe012e57f81c/src/bin/xmoji/font.c#L47

Now I can create a FT_Face from the result with #freetype. Finding and rendering glyphs to FT_Bitmap seems straight forward, but how would I get that rendered on some #xcb drawable? I found an example using xcb-render-util, but that's "only good for ~252 glyphs" -- huh? 🤨

Anyone have a good example how to do it manually with maybe just xcb-render (without pulling in the next huge lib like cairo)? Maybe @thomasadam ? 😉

@thomasadam It seems to get worse. If I interpret that correctly, the "Noto Color Emoji" font is a bitmap font, with just one (pretty large) size available.

So far, I found no means to scale #bitmap #fonts with #freetype. Is this really not covered? That would certainly be another thing I don't want to implement myself 😕 (cause, yet another case of "re-inventing the wheel").

Digging deeper, it seems "Noto Color Emoji" isn't *really* a "bitmap font" but mostly(?) includes #SVG glyphs. And of course, scalable(!) vector graphics aren't scalable from the freetype perspective (yes, it does make sense, it's even documented you need a separate renderer for these ... would I pull in an indirect dependency on #rust at this point? 🤯)

I feel like maybe giving up and instead do some gfx rendering on the good old #VIC-II of the #C64 😂

For now, accepting facts, I just "completed" my font loading code to select a "best match" fixed size for non-scalable fonts:
https://github.com/Zirias/xmoji/commit/8c4659b7c03bbd3ad15e94aa4c76e7788bd0915d

A next sane step might be to at least try to "shape" some "normal" text (not #emojis) with #harfbuzz and try to render this with #xcb #xrender ... 🤨

Quickly collecting dependencies meanwhile, this is how it looks like 🙄

I did add the first 5 (#fontconfig, #freetype, #harfbuzz, #poser, #xcb) explicitly. Poser is my own lib, it pulls in ssl/crypto for (build-time optional) support of TLS sockets. Fascinating what else I collected here 😂

Hell, there's even a C++ runtime? 🤨

Started work on some TextRenderer class/module.

Should in the end handle everything to get an #X11 #pixmap from some #utf8 text. For now, just runs #harfbuzz shaping and calculates the resulting pixel size in a background thread.

I have no idea whether my calculations are really correct. But at least, the result for a "Hello, World!" text looks somewhat plausible 😅

https://github.com/Zirias/xmoji/commit/439d0dfee46a4f40a671634a0f18d9c9accbb543

Wow, I was stalled for days now because I couldn't figure out why my queue of outstanding #X11 replies always quickly overflowed.

Turns out one factor was a simple coding error in text rendering test code, leading to repeatedly issuing the same requests 🙈.

But I didn't find that because processing also stalled. Turns out integrating #xcb correctly with your own event loop is somewhat tricky 🤯.

I guess I figured it out now, finally 🥳. And for the first time ever, I found a good use for #C11's _Generic() 😂. Screenshot is lots of debugging output, the batch of confirmed requests on the bottom is from requests uploading #glyphs, and trying to use some #xrender stuff with them. Now for the hard part: My window stays plain white ... 😒

Finally, some *visible* result from my #X11 / #xcb experimenting with #freetype and #harfbuzz for font rendering. 🥳

https://github.com/Zirias/xmoji/commit/80e953a98048419124f0a2ef72e9eaefb8812789

There are issues to fix:

* Sometimes, it renders nothing visible. I'm not sure where this indeterminism could come from 🫤
* xcb/render.h offers a struct for color with fields for red, green, bue and alpha (in this order). If I use {0,0,0,1} here, I see nothing on a white background. {1,0,0,0} gives me black text. 🤔 Now either I'm doing something *completely* wrong, or there's some confusion somewhere whether colors are ARGB or RGBA format. Huh?

There's also an issue that probably doesn't have a fix. #harfbuzz shaping outputs rendering positions in fractional pixels. I *think* XRender only accepts whole pixels, so I have to round the position for every single glyph. I wonder whether this is a reason for many to use #cairo for rendering?

@thomasadam if you can shed some light on one of these issues, that would be awesome, but I guess I'm not exactly "stuck" here, need to do more research 😅

@thomasadam Ha! Adding some color (lol) helped to identify and fix the issues 😆

There were two different ones. First, the color used was non-deterministic. Tracked that down to sometimes picking the wrong XRender picture format 🤦 (turns out there can be more than one 32bpp format available, you have to check the shift values of the color channels to make sure you got ARGB) ... now the xcb_render_color_t works as expected.

Second, sometimes it rendered nothing at all. Tracked that one down to freeing the rendering data too early, the request has just a pointer and might still be queued by #xcb 🙈

Ok, "simple" text rendering: done. ✅

@thomasadam I start wondering whether "shaping" artifacts from "rounded" #glyph positions can be avoided at all? 🤔

If I understand that correctly, you always rasterize one glyph at a time with #freetype. So, it starts at a "whole" pixel position, right? Do I overlook anything?

@thomasadam I'm using #harfbuzz to "shape" my text. It's giving me "advance" values in 1/64th pixels. To have that shaped text rendered "perfectly", you'd have to position the glyphs in that high resolution and rasterize as a whole I guess. Seems that's just not possible with #freetype though.

So, I'm using the info from harfbuzz to position individual glyphs at the nearest whole-pixel position instead. 🤷

Just wondering whether I overlooked something, but I guess that's indeed the way to go...

https://github.com/Zirias/xmoji/blob/1fb2e5e01558a6dd72cbf0048ba4389aaa48d180/src/bin/xmoji/textrenderer.c#L159

@thomasadam Taking it as it is right now (cause I GUESS there's no way to "do better", give me a hint if I'm wrong) and moving on:

I need #widgets now!

This text rendering is currently hardcoded into my "window" which is *meant* to model just some "generic" #X11 window. It should instead contain some generic widget (probably some tree of these) to show "whatever". In some sense, this would be a (tiny) "toolkit" for #xcb then ...

Years ago, I experimented with raw #win32 (but using microsoft's "common controls" lib), and there, every "control" was actually a window. From what I understood so far, you don't do that with #X11, but instead draw on your actual window surface using offset positions ... is this correct? 🤔

@zirias Without seeing the design of this’s, you should remember that there’s a difference between providing drawing primitives (widgets), and the behaviour of the window itself which behaves as widgets should.

So, for example — by all means provide pre-defined widgets with whatever meds to be in them. If you’re going down the route of providing your own primitives, Fvwm{Form,Script} will be useful to you here. Or you could use a higher-level library like Xt.

As for window behaviour, let’s talk separately about that…

@thomasadam I understand only parts of this I have to admit 😕

Currently working on "optimizing" my interfacing with #xcb first, I think I finally understood how it works (requests, replies, errors) and now I try to use that fully asynchronously with the least possible overhead (on the socket) while automatically injecting a dummy "sync" request when it's *really* necessary ... commit following soon 😏

But then, yep, widgets is what I will need. I'm thinking about completely ignoring all #X11 drawing primitives and just use #XRender for everything, hoping that's a somewhat sane thing to do 😅

@thomasadam So, I guess *this* is done:
https://github.com/Zirias/xmoji/commit/cd0a2db4f871f3d6a44dcfce6d0c76a4df93c850

The core of my fully async #xcb wrapping API are two macros I finally documented (necessary because otherwise, I'll forget myself, and some _Generic() magic isn't exactly readable 🙈):
https://github.com/Zirias/xmoji/blob/cd0a2db4f871f3d6a44dcfce6d0c76a4df93c850/src/bin/xmoji/x11adapter.h#L35

It does what I want, requests are minimized, this debug log shows the result after triggering redraws by resizing the window and minimizing/restoring it 🥳

(No excuse left now to tackle a widgets concept 😅)