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 😅)

@zirias Again, just eyeballing this far too quickly than I’d like to right now, things looks good to me.

Will look thoroughly when I’ve more time.

@thomasadam I might be sidetracked again: I guess I found a viable solution for my "glyph positioning issue".

It seems #freetype can use an offset when rasterizing a glyph:
https://freetype.org/freetype2/docs/reference/ft2-outline_processing.html#ft_outline_translate
Should be possible to use that for rasterizing 4 variants of the same glyph, shifted by quarter pixels.

A truetype font will have a maximum of 2^16 glyphs, an #XRender glyphset can contain up to 2^32 glyphs ... just adding two bits here for somewhat sane render quality seems like a good idea.

I'll try to implement that first before testing something else 🙃

@thomasadam Awesome, this is the solution 🥳: Reserve two bits of the #glyph id in the #XRender glyphset to indicate one of 4 horizontal shift positions for the same glyph. Result looks nice IMHO.

Screenshots:
1. New rendering
2. Old rendering 8x zoom
3. New rendering 8x zoom

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

@thomasadam Made the subpixel resolution configurable.

https://github.com/Zirias/xmoji/commit/8b0f0c8cdc52452afa63de9bdf439e53940d0223

Here's a render test with all possible values (0 to 6 bits subpixel precision).

Only whole pixels is barely acceptable, the kerning is just broken (see the huge gap between the two lowercase L). Two bits for subpixels already looks pretty good, more don't seem to improve the result here further although I can spot a minimal difference up to 4 bits 🙂. Seems a "sane" value should be 2 or 3 bits for this.

#XRender #xcb #text #rendering #freetype #harfbuzz

@thomasadam So far, work on #xcb-based #widgets seems pretty straight-forward.

My widget base class already does a few things, like maintain size and minimum size, padding, alignment, an inherited color-set, optionally draw a background, etc....

Only one concrete widget so far, a simple text label (at least it accepts multi-line text and calculates the line positions from the line height #freetype reports).

Here's the code constructing this super-simple window content:
https://github.com/Zirias/xmoji/blob/852788c97965bd97ea4e7e2e4461deb686ec7b4b/src/bin/xmoji/xmoji.c#L36

@thomasadam Let's see what we have so far (#X11 properties). Looks mostly sane I'd say?

But what's _NET_WM_ICON_VISIBLE_NAME, who is setting that, and how does it end up so garbled? 😦

For the window name, so far I only set _NET_WM_NAME (utf8) and WM_NAME (converted to latin1)....

@thomasadam Yes, when I set an icon name (WM_ICON_NAME and _NET_WM_ICON_NAME), the property just reflects that.

So I guess in absence of an icon name, fvwm tries to use the window name for it and reflects that in _NET_WM_ICON_VISIBLE_NAME?

Could the garbled encoding be a bug in fvwm? 🤔

@thomasadam And another "interesting" issue that only happens sometimes ... I just added lots of debug output to analyze why my Window sometimes draws when it should close, and here's the proof: that's triggered by a bogus(?) expose event (that's only sometimes received). The preceding ClientMessage is the WM_DESTROY one. Any idea what could cause this and whether I can somehow stop it from happening? 🧐

A workaround should be simple though, just stop processing expose events for a window that already requested unmapping 🙄

#x11 #xcb #programming

@thomasadam Adventures in #X11 #programming using #xcb ... I think I discovered some strange (and, undocumented?) behavior in #Xorg.

Getting more seemingly(!) "stray" Expose events, I finally discovered what's happening. I already decoupled my drawing logic from handling Expose, and instead maintain information in a widget whether it's visible and invalidated (with invalidation triggered by whatever, e.g. an Expose event). Only after processing a batch of input from the X server, I check whether a widget is both visible and invalidated, and if yes, draw it. So far a common pattern to avoid excessive drawing.

Now, setting the "root" widget (the window) visible as soon as a MapNotify is received, this *could* lead to start drawing before receiving the first Expose. Drawing still works perfectly fine, but this somehow delays the Expose event until something else "happens" to the window (like moving it), then you suddenly receive this Expose ... 🤯

Solution: Only set the window "visble" after the first Expose event is received...

I guess it would be impossible to trigger this with #Xlib because its API makes you wait for the response to every request... 😉

@zirias Yeah. That’s probably not the best approach.

Not sure if you’d be up for it, but I’d be more than happy to spend some time with you on IRC or Jitsi to go through this with you, if that’s helpful?

@thomasadam Thanks, I just asked over there (libera) 😉

Meanwhile it *seems* to all work, so the next "big thing" would be to find a way to #render #SVG (and maybe #PNG) #glyphs for "color emojis". I hope to avoid librsvg for that (would pull in rust and cairo ...), so, will test alternatives...

Weird, I remember reading something somewhere on the noto fonts github that seemed to suggest the emoji font used SVG graphics. But peeking into freetype's face and glyph structures with lldb, it looks more like it's plain RGBA bitmap data ...

Well then, just need to figure out a good way to scale that.

I wonder whether it's possible to do #XRender #CompositeGlyphs requests with a scaling transformation applied? This would certainly be the simplest solution.

Any #X11 or #xcb experts here? 😅

Had an idea, pure genius 🙈: Just check how #Xft is doing it.

Well, turns out it's literally "just doing it":
https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/master/src/xftglyphs.c?ref_type=heads#L327

Maybe I should just do it ... 😅

#X11 #xcb #XRender #scaling #bitmap #font

Rendering a color #glyph with #XRender was the first issue, finally solved. It's surprisingly complicated, because with XRender, a glyph is always an alpha mask, and if it has 4 channels, the actual alpha channel is ignored and the color channels are interpreted as per-component alpha.

To get a sane rendering, I had to create two(!) glyphsets for colorfonts, one ARGB, one alpha only. First render the ARGB one to a temporary pixmap. Then use this pixmap as the source for rendering the alpha glyphset to the real target. Oh, wow 😅

Now, time to improve scaling, just did a stupid "nearest neighbor" for the first poc ... (screenshot looks good because it's unscaled)

Replaced the super-stupid "nearest neighbor" with some still pretty naive averaging, and yes, that's slightly better, but I guess I won't be happy with that ...

probably time to dig deeper into "good" #scaling (#resampling) algorithms

Aha! A simple filter matrix improves it a lot:
https://github.com/Zirias/xmoji/commit/79aab888be379303ad8cafdd27f34f91b276275f

I guess that'll do for my purposes. Far from perfect, but IMHO acceptable 😅

played a bit more with the shape of my filter matrix and now I'm really happy 🥳

rendering a scaled color #bitmap font with "pure" #X11 (with #XRender) using #xcb: done! ✅