Taiwins 0.3 Released As Newest Wayland Compositor Release

[blacknova]

Does anybody really use the font and shape drawing API anyway? Those are severely dated, and the reason why people complain about X's bloat...

Right now? Of course not, it is indeed outdated. But is it a good idea to have centralized font rendering, IMHO yes.

[acobar]

That stopped being the case in the year 2000.

https://gitlab.freedesktop.org/mstoeckl/waypipe

The reality here is X11 server over network since at least year 2000 has basically been like waypipe if you want full functionality.

acobar VNC is not the only option here. Waypipe shows that from wayland core protocol does not need to change to support network rendering.

.

We all know that X is total crap from a security POV, no question about it. Let's see how Waypipe develops because right know I have to use nomachine (had no luck with xrdp and didn't try the most recent versions) and it still has some problems with Wayland.

[oiaohm]

Right now? Of course not, it is indeed outdated. But is it a good idea to have centralized font rendering, IMHO yes.

No this is wrong. There are 4 simple worlds that describe the problem.
"Single Point of Failure"
Client side font rendering removed a single point of failure. Centralized server based font rendered ends up with all the applications different fonts being rendered in the central server so resulting in higher memory usage in this part that can mean it can come first killed by the out of memory kill and when it goes the output of all applications can go as well.

Its why the arguement with nvidia over eglstreams design.

Ideal world applications should be able to stand on their own two feet if the X11 server or wayland compositor goes way until it comes back.

[blacknova]

No this is wrong. There are 4 simple worlds that describe the problem.
"Single Point of Failure"

On the other hand single well tested, even unit tested font rendering server might be stable enough for this to not be an issue. And good design might even provide a way to recover from server restart without applications failure.

Client side font rendering removed a single point of failure. Centralized server based font rendered ends up with all the applications different fonts being rendered in the central server so resulting in higher memory usage in this part that can mean it can come first killed by the out of memory kill and when it goes the output of all applications can go as well.

Client side rendering keeps private copies of rendered glyphs for each application, thus resulting in higher memory usage. Font rendering server on the other hand can have each own cache, which will be shared between all applications. In since most applications in same DE would use similar font overall memory consumption will be lower. And it is bad design if system or desktop service would be killed by oom daemon.

Its why the arguement with nvidia over eglstreams design.

Ideal world applications should be able to stand on their own two feet if the X11 server or wayland compositor goes way until it comes back.

In ideal world application should rely on system, application server or DE services to provided for everything not related to main functionality. I.e they should follow the KISS principle. If you want menu rendering you just want them rendered by provided structure, not the whole process of doing it. Right now this problem is being solved by different TK.

[oiaohm]

On the other hand single well tested, even unit tested font rendering server might be stable enough for this to not be an issue. And good design might even provide a way to recover from server restart without applications failure.

This is you not understanding the problem.

Client side rendering keeps private copies of rendered glyphs for each application, thus resulting in higher memory usage. Font rendering server on the other hand can have each own cache, which will be shared between all applications. In since most applications in same DE would use similar font overall memory consumption will be lower. And it is bad design if system or desktop service would be killed by oom daemon.

This is in fact false these days. Client side rendering results in less memory usage today. The reason why today is font hinting.

https://github.com/lxnt/zhban

As those who do font caching find out at each size for each char you need 64 glyphs at least due the 1/64 of a pixel placement adjustment. This get harder that the way font hinting is done need to adjust based on contrast between text and background. So this works out to times by 10 again. 640 glyphs per char.

Per application with glyph being rendered straight on to the output buffer of the application with no cache is lighter in memory than using a cache. Heavier on CPU. Yes even with most applications using the same font there the saving are really not there. Font hinting to provide better text for human eyes has results in font caching not being cheap any more.

https://en.wikipedia.org/wiki/Kernel_same-page_merging you have to remember we have had copy on write for a long time and today we have same page merging as well.
So if two applications generate the same glyph and they are page aligned the same way(that library like freetype can make sure of) they will merge by the kernel so again not result in extra memory.

Its also possible to do font glyph caching using file storage this has the ablity to be mapped into memory so automatically copy on write shared without requiring a server. This is kind of not done due to the direct elephant in the room how large each font will be due to how many glyphs you need due to font hinting. Yes the font file being loaded by all the individual applications end up being copy on write shared between all applications using that font so not causing increased memory usage.

blacknova talking about possible memory usage saving with a font server turns out to be total crap. One of the reasons why font server disappeared from X11 was to provide memory usage saving that the change has done. The valid issue if it is a issue is the increased cpu usage but having mountain of cached glypths to search though is also a big ass cpu consuming problem when you run a server as well with caching.

Please note windows and OS X these days also don't have a font server any more they are also using client side rendering of glypths.

In ideal world application should rely on system, application server or DE services to provided for everything not related to main functionality. I.e they should follow the KISS principle. If you want menu rendering you just want them rendered by provided structure, not the whole process of doing it. Right now this problem is being solved by different TK.

One of the other things is CPU time scheduling. Application can be doing very little in its own process yet be asking DE services to-do a lot. How should the kernel allocate it time so every application is getting a fair allocation.

Applications having run what it need or toolkit in their own process where possible means its simpler to allocate CPU resources fairly between them. This lack of fairness problem is more a issue the more cores our CPU has.

This idea really no longer works I could processed to systematically pull this apart maybe seeing where you went wrong with the font server will make you work out the reason why a lot of things are being pushed back to toolkit is with copy on write and kernel same page merging a lot of things don't make sense being in application server de services any more. Modern day systems a lot more things make sense to be done in the applications own process, cpu and memory allocations.

[lyamc]

I hope this becomes mainstream so that Chinese devices start running a piece of software that reminds them of Taiwan

[t.s.]

Over history there has been over 30+ different implementations of the X11 server bit with no common shared code. There is also over 13 different X11 compositors.

last 20 years of Linux we got use to X11 server=x.org X11 server without the competitors. The reality is before 2000 there were quite a few different X11 servers that commercials parties were selling for Linux, BSD and Unix systems.. The early time frame of X11 is quite fragmented.

Then, let's make it (wayland compositor) way past 30+. We're in ~33% now. just need some ~67% more. Yay!.

[t.s.]

I love how the X fans pretend that X was such a stable solution for all those years when in fact it was not, it was everything but a standardized proper working system. At best, you could say that its somewhat acceptable since the DRI3 release in 2013.

Majority is not a fan of X. Just that wayland is still have quite long way to replace X, and like it or not, they still have to use X. Myself, have following wayland news from it's first inception. And at around 2018, hoping that it'll soon materialize in major DE (and my favourite DE, KDE) and usable. Here we are, half 2021. And wayland still far from usable (except gnome, maybe)..

[Vistaus]

Right now? Of course not, it is indeed outdated. But is it a good idea to have centralized font rendering, IMHO yes.

Exactly! Every font I ever tried, including a lot of high-quality ones, always looked different depending on the toolkit. A centralized way would be nice.

[Vistaus]

No this is wrong. There are 4 simple worlds that describe the problem.
"Single Point of Failure"
Client side font rendering removed a single point of failure. Centralized server based font rendered ends up with all the applications different fonts being rendered in the central server so resulting in higher memory usage in this part that can mean it can come first killed by the out of memory kill and when it goes the output of all applications can go as well.

Its why the arguement with nvidia over eglstreams design.

Ideal world applications should be able to stand on their own two feet if the X11 server or wayland compositor goes way until it comes back.

How about central font rendering and a toolkit fallback? That way, font rendering would still be central but you will still see some text when the X server goes haywire.