@thomasadam @peppe Thanks for that! I totally forgot about the decorations topic, which is of course very relevant, it means even jumping through the hoop and implementing a #wayland compositor, you can only deliver part of the functionality (and almost none of the looks) of your window manager.

But even with that issue solved, I would really dislike wayland's design. Although I *do* think that most of #X11 core drawing is obsolete and useless (mostly for the missing alpha channel), I think a display server should offer drawing facilities. Replace X with something dropping lots of cruft (indexed palettes, COMPOUND_TEXT, etc), instead incorporate extensions that everyone needs these days, extend #XRender (now as part of core) to offer more drawing primitives, etc ... you could have a replacement for X11 that's worth dealing with. And window managers could still be separate clients.

@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....

In a nutshell, a major rework of what the X core protocol supports would be necessary.

But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.

@matuzalem Regarding the broken output, looks like yet another issue with #XRender Obviously a different one than I observed on my GPU and worked around with the "-glitches" flag. Does it work in an environment without any hardware rendering (like #Xephyr)?

@thomasadam YES!

The occassional flicker was *only* caused by several #XRender requests accidentally hitting different frames. Easily solved using a "backing store" pixmap, so a single render request is enough for every (rectangular) update. No need to fiddle with vsync or anything.

Next step completed, my #TextBox widget now supports mouse input: click, doubleclick and drag .

Not so nice: With overall more drawing operations, I see #flicker happening more often . Did some research already, it seems with #XRender, the only way to avoid it would be to render to some #pixmap (instead of the window directly) and use #XPresent to get it on the screen? @thomasadam do you know an "easier" way?

Adventures in #X11 #programming with #xcb and #XRender: THE UGLY ...

Took me hours(!) to figure out what's going on here. Once I discovered this rendering bug goes away when I force DRI2 with EXA (instead of DRI3 with Glamor), I was finally sure there's a bug outside my code. Never seen it in any other X11 application, but I guess XRender isn't used that much nowadays.

Well, for now, added a "glitch flag" to enable a workaround:
https://github.com/Zirias/xmoji/commit/b77a9e53397907d253f26715a6a5d1d79c49971b

Selections: done. Rendered using a pre-colored src picture using #XRender #composite #glyphs (Still only keyboard input, mouse will be next)