Announcement

Collapse
No announcement yet.

Taiwins 0.3 Released As Newest Wayland Compositor Release

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

  • #31
    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.

    Comment


    • #32
      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.

      Comment


      • #33
        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.

        Comment


        • #34
          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.

          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.

          Comment


          • #35
            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.

            Comment


            • #36
              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.

              Comment


              • #37
                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.

                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.


                Comment


                • #38
                  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.

                  Comment

                  Working...
                  X