|
Top-level
 These days we have 4k HDR screens. Such a screen's framebuffer comes in at 2×32MiB (double buffering). And in a compositor based graphics system such as Wayland, each every window will hog up to 32 MiB, even if minimized or otherwise hidden, so that quick preview will work. For 8k screens you've multiply those numbers ×4. Assuming a GPU with 8GiB VRAM that's just 250 windows you can fit in there. And of course you've to bear the needed memory bandwidth, too. 2/ 4 comments
Bottom line is: FOSS has to do it's glyp rendering on CPU and either transfer the whole rendered text for each content change (more resource efficient) or has to upload humongous font atlases – good look if you want to render logographic script. So that's inducing a bottleneck. The lesson here is: The graphics related resource constraints of 40 years ago never went away. They just bode their time, and now are rearing their ugly heads again. 4/ So in conclusion: Of course a graphics system developed with the constraints in mind (because it wouldn't have worked otherwise) will perform a lot better on modern systems, than graphics systems designed toward the needs of 15 years ago. /fin  @datenwolf @hanser @nblr and is still more stable than modern wayland. in fact when wayland crashes it takes all your programs down with it, The devolpers who designed wayland cant do what x did 20 years ago. |
Gregory's Server
@Hunterrules0_o @hanser @nblr
But there's more: For a long time GPU accelerated font rendering was elusive. Eventually Eric Lengyel solved the problem with his SLUG library. However the algorithm is patented to FOSS can't use it.
In 2015 I did work on GPU accelerated font rendering, too. However when SLUG got released I was wary that its algorithm might be similar to mine (I'm now confident, that my algo is sufficiently different to not infringe patents).
/3