Announcement

Collapse
No announcement yet.

2D Performance Also Impacted By Unity On XMir

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

  • #11
    Originally posted by ickle View Post
    Which is odd since they accelerated gradients since the 295 series of drivers - except for a few corner cases iirc. Their driver developers are very active, have you spoken to them about this? Perhaps provide them with a cairo-trace so they can analyse the failure path?
    Yes i did, and i've spoken them about a cairo performance regression.
    Hi, as stated here: [url]http://www.nvnews.net/vbulletin/showthread.php?p=2418346[/url] The cairo-1.10.0-buggy_gradients.patch shouldnt be needed anymore, but i tried unpatched cairo 1.12.8 with nvidia drivers 310.14(beta), 304.60 and 304.51. With those drivers gtk applications are very slow, even firefox is slow when scrolling pages using native widgets. Applying the cairo patch OR using nouveau make things smooth again. Users complaining: [url][workaround] 100% CPU load in GTK2 applic...


    They may hae been busy, i can't say

    Still, a poor ATI 7500 (about 10 years old?) does a better job though OSS drivers, and the same card with nuoveau just flies in that regard.

    Originally posted by Teho
    Wayland will be supported natively by Qt 5.2 and later; not by Qt 4.
    How can kwin in 4.11 work with wayland then?

    Comment


    • #12
      now lets put it into an LTS

      Comment


      • #13
        Originally posted by kokoko3k View Post
        Yes i did, and i've spoken them about a cairo performance regression.
        Hi, as stated here: [url]http://www.nvnews.net/vbulletin/showthread.php?p=2418346[/url] The cairo-1.10.0-buggy_gradients.patch shouldnt be needed anymore, but i tried unpatched cairo 1.12.8 with nvidia drivers 310.14(beta), 304.60 and 304.51. With those drivers gtk applications are very slow, even firefox is slow when scrolling pages using native widgets. Applying the cairo patch OR using nouveau make things smooth again. Users complaining: [url][workaround] 100% CPU load in GTK2 applic...


        They may hae been busy, i can't say

        Still, a poor ATI 7500 (about 10 years old?) does a better job though OSS drivers, and the same card with nuoveau just flies in that regard.


        How can kwin in 4.11 work with wayland then?
        Wayland work started befor QT 5.2

        Comment


        • #14
          On the other side, Compiz 0.9.10 in Ubuntu 13.10 will probably introduce buffer_age support, which will speed some things up.

          Comment


          • #15
            Originally posted by spacetoilet View Post
            Wayland work started befor QT 5.2
            Speaking of kde4.11, the question was if kwin was ported to qt5 to work with wayland

            Comment


            • #16
              Originally posted by kokoko3k View Post
              How can kwin in 4.11 work with wayland then?
              It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

              The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.

              Comment


              • #17
                Originally posted by dee. View Post
                It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

                The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.
                Thank you.

                Comment


                • #18
                  Originally posted by dee. View Post
                  It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

                  The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.
                  There is also a new native software implementation to replace Xrender:
                  One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, …


                  This one is only compatible with wayland for the moment.

                  Comment


                  • #19
                    Originally posted by BO$$ View Post
                    OK so probably in 13.10 we'll take a performance hit. Hopefully the impact will be smaller, much smaller than it is today.... Get to work Canonical, only a few months left. Get it right a lot of people will think better of you. Get it wrong and haters will complain about this performance loss for another decade, even if it will have been fixed in 14.04.


                    One of the reasons for this result set is missing composite bypassing support, which we are aware of since January. Composite bypass helps when apps/benchmarks run fullscreen because? well, because they don?t need to be composited. Gamers out there? there is hope and a plan in place to get you your precious FPS back. This feature/bug is currently scheduled once other key functionality landed. Also, in order to make FPS based benchmarks really count, we need eglSwapInterval(0) implemented, which is currently in progress

                    Comment


                    • #20
                      Originally posted by TheOne View Post
                      http://www.olli-ries.com/first-mir-benchmarks/
                      One of the reasons for this result set is missing composite bypassing support, which we are aware of since January. Composite bypass helps when apps/benchmarks run fullscreen because? well, because they don?t need to be composited. Gamers out there? there is hope and a plan in place to get you your precious FPS back. This feature/bug is currently scheduled once other key functionality landed. Also, in order to make FPS based benchmarks really count, we need eglSwapInterval(0) implemented, which is currently in progress
                      All of this would have been a non-issue if they'd have stuck with Wayland.

                      Comment

                      Working...
                      X