@bamboombibbitybop @lfa it tells me it's a project I wouldn't want to join. I still wouldn't mind to see anything technically good come out of it, although I don't expect that. It would be great to see some general progress. The #Xrender / #Glamor bug I reported quite a while ago was confirmed very quickly and then nothing else happened... 😞
Oh please someone keep #X11 alive. Sure, preferably not the "make X great again" way 🙈
@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.
Ok, first reaction (confirming my suspicion that #glamor causes the bug) was super quick, I'm impressed! Let's see whether anyone jumps in soon to actually analyze the root cause. 😎
JFTR, it's the bug I already probe for in #xmoji to enable a silly workaround when necessary, applying a transformation to the source picture.
Well, I really like #X11 (#Xorg) ... and my son loves #PeppaPig. Which gives me a stupid idea. I could write something called #Xchicken. Make some chicken lay some eggs with mouse clicks on some #XRender surface.
Rough roadmap:
- Draw some chicken and eggs, probably as SVG?
- Reuse code from #Xmoji, add special widget supporting some "layered canvas"
- Implement game logic
- Add sound? (Hm, gotta look into #OSS and maybe #sndio, cause #FreeBSD ... #Linux weirdness maybe later)
- ....?
I'll probably never start though 🙈
I want to finally resume work on #Xmoji. Starting with a bit of house-keeping, I factored out a function probing for a weird #XRender (presumably only with #glamor) bug, so it doesn't distract from the normal X client startup, and took the opportunity to also document it:
If anything is really wrong with #X11 or #XOrg, it's bugs like this 😔 ...
@0x1eef That's unrelated, it's about a glitch actually rendering the glyphs with #XRender compositing, there's a bug getting source coordinates wrong, and I *assume* it's triggered by the "glamor" acceleration, the message just says the buggy behavior was detected and a workaround enabled.
Did you shorten that log? I also added debug messages from TextRenderer showing the effective harfbuzz properties. If you don't see them at all, that would certainly indicate a problem, but in a different place 🧐
I just added code to #Xmoji applying #hinting settings from #fontconfig. I had an immediate reason... 🤔
Rasterizing my glyphs with #freetype (for rendering with #XRender), kerning breaks horribly for Microsoft fonts using the "native" truetype hinting. Forcing freetype's autohinter instead, it's (almost) fine (but hinting itself might be slightly lower quality).
Am I doing something wrong, or what the ... is the problem here? Example screenshots using "Segoe UI".
@samurro @governa KISS, like any principle, needs context to apply: What is "it" here? There's a set of requirements for a "desktop environment", which is very complex. One way to achieve KISS for something like that is a good break-down into "simple" modules. #Wayland set itself a very limited scope (more or less just compositing), so sure, that's a good start.
Looking at the whole system built around that, I have doubts that's really #KISS. We'll need input handling ( -> libinput, xkb), inter-client communication ( -> dbus), client rendering ( -> cairo et al), to name just a few obvious ones.
#X11 already has these aspects integrated. They're still organized into modules. Having all the aspects (almost) every "desktop app" needs available in the one server process has the potential to reduce overall complexity.
I know that's not where we are with "modern desktops" running on #X11. That's because X11 is full of "old cruft" not matching today's requirements (like its core drawing/input/fonts etc), while development of modern replacements (like #XRender) stalled ... at least partially because developers were drawn towards #Wayland instead. That still doesn't convince me Wayland is the better concept. 🤷
Finally removed the nasty "glitches" setting from #Xmoji!
After lots of (unsuccessful) research whether I can somehow check which modules(!) are loaded on the X server (to find out whether #GLAMOR is used, which I *think* causes a bug in compositing glyphs with #XRender) ... I finally remembered an old strategy which is both horribly ugly and pretty reliable: probing!
I now do a dummy glyph compositing to a single-pixel off-screen pixmap during startup and fetch the resulting pixmap from the server, so I can simply *see* whether the result is buggy. 🙈
https://github.com/Zirias/xmoji/commit/93143775e6ad9b01f7f23b2da48c5e6921669fd0
I actually wonder why I didn't have that idea much earlier. E.g. coding on the #C64, probing the hardware (e.g. to identify VIC and SID model by their behavior) is a pretty common thing to do 🥸
I guess I "fixed" it now, this looks pretty obvious, right? 😎
Using triangles to render an X is really a "fun" exercise btw 🤯
Working on #Xmoji, I currently just try to add a little convenience feature: Give the text box a "clear button".
For rendering that with #XRender, I used the TriStrip request for a series of 3 triangles. So far, so good, but any other angle than 45 degrees results in very ugly aliasing artifacts unless I enable imprecise/smooth polygon rendering. Unfortunately this is unacceptable because in imprecise mode, the edges between the 3 triangles suddenly become visible as well. 🤯
So, going with 45 degree edges only now. You tell me whether this looks like a "clear button" to you? Thanks! 😅
Tricky question about #X11 (with #xcb) #programming:
Is there a way to determine from an X client whether the X server uses #glamor acceleration?
Background, I experienced a rendering bug compositing #glyphs with #XRender where the source coordinates don't work as expected. I found a workaround (that of course breaks when the bug is *not* present): Apply a transformation to the source picture.
I now suspect it's glamor introducing this bug, independent from the actual GPU driver. So it would be awesome if I could automatically enable the workaround when needed. I guess it's not possible though, but hey, I can ask 😎
@matuzalem Thanks for hunting this down! I'm already not to happy that I *did* need to implement a glitch mode for some hardware-accelerated #XRender at all, but at least it isn't a new glitch then (but the very same as on my old radeon GPU with glamor)! 👍
@matuzalem Well, maybe you could install xephyr (pkg install xephyr) to double-check this is indeed some glitch with "accelerated" #XRender? (in Xephyr, it will use software rendering....)
@matuzalem Unfortunately I don't know. The misaligned emojis look the same as on my machine without the 'glitches' setting, but then, enabling it solves it here, obviously not for you. And I have no idea what could cause the black background color.
You *could* try running with '-glitches 1 -backingStore 0' which is just a shot in the dark in case it's the compositing from off-screen pixmaps going wrong here.
I really like the concept of #XRender, but it seems it's quite a bit buggy in practice. The Qt version probably does full client-side rendering, so isn't affected....
