Announcement

Collapse
No announcement yet.

Taiwins 0.3 Released As Newest Wayland Compositor Release

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • t.s.
    replied
    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.
    Not a fan of GNOME. Resource hog and inefficient (too much step to achieve something). I rather use XFCE, but as we know, doesn't have wayland. Enlightenment, last time I check (around september - december 2020), still cannot start wayland or have too much problem to be usable (I tried it with archlinux on virtualbox). I'll try E24 again when have spare time. If E24 run as intended, it's more usefull DE than GNOME IMO.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by dpeterc View Post
    I have been using XFT with X11 applications since 2008, and it runs very well, not slow at all.
    Originally posted by blacknova View Post
    XFT 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.
    2008 you are using client side rendering Xft as the Xrender extension is gone by that point and it does have a problem.
    https://www.freedesktop.org/wiki/Software/Xft/
    Drawing anti-aliased text with the core protocol involves fetching pixels from the destination, merging in the glyphs and shipping them back.
    This here as they note is a problem over network. High latency between the server and the client equals anti-aliased text not be good. Note if you read on they say non anti-aliased text is fine because the client side can send without care about what the the background the text is going on.

    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.


    Leave a comment:


  • blacknova
    replied
    Originally posted by dpeterc View Post
    I have been using XFT with X11 applications since 2008, and it runs very well, not slow at all.
    XFT 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.

    Leave a comment:


  • dpeterc
    replied
    Originally posted by blacknova View Post
    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.
    I have been using XFT with X11 applications since 2008, and it runs very well, not slow at all.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by blacknova View Post
    AFAIK 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.
    If you are comparing on memory usage and cpu usage the Mesa on-disk cache beats memcached hands down.

    memcached is not that great. Its really simple to forgot a file system is really a shared object system.
    https://en.wikipedia.org/wiki/Transcendent_memory
    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 Post
    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
    There are 3 reasons.
    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 Post
    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.
    There has not been a version of GTK+ that was using X11 font server. Yes 1996 when GTK starts there is a move away from the font server at that point by the toolkits before the X11 server starts killing it off.

    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.

    Leave a comment:


  • blacknova
    replied
    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.
    AFAIK 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.

    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Vistaus View Post
    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.
    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.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by t.s. View Post

    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)..
    GNOME and Enlightenment run quite alright on Wayland, but there are still issues left to resolve and features left to be implemented.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by oiaohm View Post

    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.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by blacknova View Post

    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.

    Leave a comment:

Working...
X