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! ✅

Code for testing emoji rendering ... containing emojis ... naturally! 😁

Coding in C is still the most fun.

More progress exploring #X11 #programming with #xcb 🥳

Added a first "container #widget", a vertical box, allowing me to display two "text labels" at the same time!

Screenshots:

1. No arguments (which will just ask #fontconfig for "sans" and "emoji" to get the respective system defaults)

2. '-font Cambria-18 -emojifont emoji-24'

3. '-font Calibri-18 -emojifont "Twitter Color Emoji-24" -- this one shows there's work left to do, obviously the twitter emoji font uses #SVG for color glyphs ... (so I'm getting the uncolored outlines instead)

#xcb #X11 #programming adventure continued... I managed to add SVG support! 🥳
https://github.com/Zirias/xmoji/commit/05ceefbec24364f42173dadf0bb6bbdcb2653843

Thanks to #nanosvg, I could avoid the dependency "monster" librsvg (pulling in rust and cairo). As long as such nice "just do the thing as simple as possible" #opensource projects exist, good software engineering isn't dead yet!
https://github.com/memononen/nanosvg

Connecting this to #freetype wasn't that hard, except for the "calculate font metrics" part, which I almost certainly got horribly wrong, i just did trial&error until the #Twitter #emoji font looked somewhat sane. 🙈

Here's a screenshot using these SVG emojis in 56pt ... and for comparison Google's "Noto" emojis (scaled by my own bitmap-scaling code) in the same size.

Fixed the #metrics calculations for #SVG #glyphs, replacing most of the floating-point calculations by fixed-point arithmetic using the same formats (26.6 numbers with 16.16 factors) like #freetype. 😎

I'm pretty sure they're really correct finally, I could remove some band-aid extra downscaling that previously hid imprecisions.

IMHO not so nice, but this seems to be a property of the Twitter Emoji font: There's absolutely NO spacing between most of the glyphs 🧐

I tried to fiddle with the 3 different "advance" metrics present in freetype structures, but that doesn't have *any* effect on the glyph positions returned by #harfbuzz (anyone have any idea why? 🤨)

Screenshot shows emojis in 65pt size, below for comparison using the bitmap "Noto Color Emoji" font.

#xcb #X11 #programming

Next thing is working on a #TextBox #widget. This will require, among other things, translating between pixel coordinates and string positions (for selections and drawing a cursor at the correct position).

Of course, #harfbuzz operates on #Unicode codepoints, stored as 32bit unsigned integers. So, yesterday, I started implementing a string class holding the value in both #utf8 and #utf32 and converting between these.

Now I realized this wasn't all to helpful, so I'll start over. What I want is some immutable string class using char32_t internally and offering functions to create mutated clones...

#xcb #x11 #programming

Ok, I now have my immutable string class, featuring static const initialization and, for dynamically allocated instances, reference counting:
https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/unistr.h

... plus a mutable variation the intended #TextBox #widget should operate on, offering a "view" on its internal data to optimize passing temporaries:
https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/unistrbuilder.h

Now, I still can't start implementing this widget. First I have to implement getting #keyboard #input with #xcb. I figured I probably won't need #xkb for my purposes, processing core #X11 events should be enough. Of course this involves holding the keyboard mapping state myself 🤨

I can't use any "xcb-util" stuff as this would interfer with my async model integrating xcb with a generic event loop ... but at least I can read this code to figure out how things are supposed to work:
https://gitlab.freedesktop.org/xorg/lib/libxcb-keysyms/-/blob/master/keysyms/keysyms.c?ref_type=heads

Digging a bit deeper, I now figured core #X11 won't help me getting compose-key sequences right? I guess I will need #xkb for this?

Asking experts again to correct me if I'm wrong please ... @thomasadam 😂

Well if that's the case, #xcb offers xkb of course, but it's a damn complex thing. I guess I'll accept yet another dependency instead: #xkbcommon 😉

@thomasadam #xkbcommon is really helpful. Was quite easy to integrate so I can fire my own "keypress" events "enriched" with the correct #X11 keysym (minus control translation, which IMHO isn't all too helpful anyways) plus a set of currently effective modifiers.
https://github.com/Zirias/xmoji/commit/86f47445186114dae3a41e2d9078f0bd104d1234

No compose processing yet, I assume this should better be done per window... (?)

A potential issue I see is that xkbcommon uses #xcb reply functions in some places. It won't break my scheme as long as I only call xkbcommon functions from within my own event/reply handling code, but it *could* in the worst case block for a short time 😕 (possibly when the keyboard mapping is changed)

That'll be a lot of work 😎

Started implementing a #TextBox widget. So far only appends what's typed and draws a (non-blinking) cursor at the end 🙈

#X11 #xcb #programming

Ok, my #textbox #widget now has complete support for line editing using the keyboard ... and a blinking cursor 🥳

Still missing: Selections and any sort of mouse support 😉

#X11 #xcb #programming