Originally posted by t.s.
View Post
Announcement
Collapse
No announcement yet.
Taiwins 0.3 Released As Newest Wayland Compositor Release
Collapse
X
-
Originally posted by Vistaus View PostHow 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.
Remember mesa3d is able to use a shared cache without having a central server.
Remember since year 2000 for most X11 applications you have been using client side rendering of fonts. Also since 2000 most X11 toolkits don't use X11 2d graphics primitives. The reality when you look at what the X11 server is doing its for the past 20 years its not much. Yes people do ask for features of X11 that have not been used for 2 decades or more in reality of anything other than legacy app support as prior to year 2000 applications no one is bothering updating.
- Likes 1
Comment
-
Originally posted by oiaohm View Post
Still end up with single point of failure and double effort. Thinking denial of service. Central font rendering could be telling the applications its font rendering when its not when it goes haywire. The double stacked like you described was tried with X11 server as well back before 2000. You also have a increased cpu usage because every text render its like is the server up do I have to render myself.
Remember mesa3d is able to use a shared cache without having a central server.
Remember since year 2000 for most X11 applications you have been using client side rendering of fonts. Also since 2000 most X11 toolkits don't use X11 2d graphics primitives. The reality when you look at what the X11 server is doing its for the past 20 years its not much. Yes people do ask for features of X11 that have not been used for 2 decades or more in reality of anything other than legacy app support as prior to year 2000 applications no one is bothering updating.
The reason everyone abandoned X11 API is quite simple it is outdated, standard X11 do not handle well vector fonts, it doesn't support by default rgba/argb visuals as result it doesn't play well with font and primitive rendering anti-aliasing. Since this functions are part of the core protocol, and Xft and Xrender didn't get much traction on top of Xrender being just plain slow everyone shifted their toolkit to complete client-side rendering. No one were willing to extend core protocol, to much work, compatibility issues, etc. Nothing new really
Mind you I still remember transition from GTK1.x to GTK2.x and that was a pain, on the same hardware GTK2.x and GNOME2.x were painfully slow, so not everything was being nice and fast with client-side rendering.
Comment
-
Originally posted by blacknova View PostAFAIK Mesa uses on-disk shared cache. It is possible implementation, though for fonts I'd prefer something like memcached. This way you can have shared cache and no-centralised font-server. That doesn't change that each toolkit try to play by it own rules and fonts look different.
memcached is not that great. Its really simple to forgot a file system is really a shared object system.
Lot of ways it would be really nice to have a proper Transcendent memory supporting file system. So a tmp fs where when you go to access a file it might be gone if no party had been using it.
Notice something here I am not talking run a service any more instead this is a kernel feature that would be useful. Yes a intentionally lousy tmpfs that auto loses files that are not in use would have a lot of different uses.
Originally posted by blacknova View PostThe reason everyone abandoned X11 API is quite simple it is outdated, standard X11 do not handle well vector fonts, it doesn't support by default rgba/argb visuals as result it doesn't play well with font and primitive rendering anti-aliasing. Since this functions are part of the core protocol, and Xft and Xrender didn't get much traction on top of Xrender being just plain slow everyone shifted their toolkit to complete client-side rendering. No one were willing to extend core protocol, to much work, compatibility issues, etc. Nothing new really
1) Patents. https://www.freetype.org/patents.html so a lot of forms of hint were patent problem. That made complexity to updating the server side.
2) Performance even using the outdated there were performance and memory issues that would get worse as you went more multi core.
3) Final nail no one was really wanting to-do the work with no gain. The server solution was not going to be a gain as multi core systems came more common.
Originally posted by blacknova View PostMind you I still remember transition from GTK1.x to GTK2.x and that was a pain, on the same hardware GTK2.x and GNOME2.x were painfully slow, so not everything was being nice and fast with client-side rendering.
GTK2 has a lot of API issues with trying to get the foundations in for multi thread support. Most of gtk2.x problem was not client-side rendering but locking hell. Of course at the time the fact multi core systems were coming were see able no one dreamed that we would get 4 cores and be stuck there for like a decade on desktop.
The fun reality here is GTK1.x and GTK2.x are both rendering the same amount of the interface client side. So that point is not a difference in client side rendering but what happens when you go from single threaded to multi threaded. Yes having a single threaded cpu having to handle locking features only need for multi cpu is a waste of cpu time leading to lower performance. Lot of people missed that if a person had a 1ghz or higher processor they were more likely to have a multi core so more likely to get the advantage out of the locking GTK2 had. This is why GTK1 vs GTK2 end up leading one group saying GTK1 is better than GTK2 and the reverse because what one was better more came down to core count.
This is another problem blacknova a lot of people like you pull up examples where client side rendering is meant to be the problem but in reality that is not what went wrong or what the difference was.
- Likes 1
Comment
-
Originally posted by blacknova View PostThe reason everyone abandoned X11 API is quite simple it is outdated, standard X11 do not handle well vector fonts, it doesn't support by default rgba/argb visuals as result it doesn't play well with font and primitive rendering anti-aliasing. Since this functions are part of the core protocol, and Xft and Xrender didn't get much traction on top of Xrender being just plain slow everyone shifted their toolkit to complete client-side rendering. No one were willing to extend core protocol, to much work, compatibility issues, etc.
Comment
-
Originally posted by dpeterc View PostI have been using XFT with X11 applications since 2008, and it runs very well, not slow at all.
- Likes 1
Comment
-
Originally posted by dpeterc View PostI have been using XFT with X11 applications since 2008, and it runs very well, not slow at all.Originally posted by blacknova View PostXFT itself is not slow, but Xrender in general was very slow compared to client side blending. Software only implementation. Not all drivers had it accelerated either as far as I can remember.
Drawing anti-aliased text with the core protocol involves fetching pixels from the destination, merging in the glyphs and shipping them back.
Getting the information for client side blending turns out to be a problem that fixed in wayland.
There have been a lot of changes to the X11 protocol over time. 2008 XFT is not server its full client side using core X11 protocol without Xrender to get background data. Also 2004-2006 you start seeing toolkits starting to use Opengl backend to side step the performance limitations of XFT anti-aliased fonts. Yes this is just like the wayland protocol where the application is using a single buffer for the window contents instead of sending individual elements to X11.
Comment
-
Originally posted by Vistaus View Post
GNOME and Enlightenment run quite alright on Wayland, but there are still issues left to resolve and features left to be implemented.
Comment
Comment