Announcement

Collapse
No announcement yet.

Alt-tabbing & maximize/unmaximize became slow in Ubuntu 9.04/fglrx 9-4

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

  • #31
    I suppose if you download Ubuntu's src.deb of X.Org 1.5 you'll find the patches in there.

    Comment


    • #32
      According to the devs. on the beta mailing list the issue (slow responses with Compiz) is more likely an issue with Compiz itself rather than the xserver. Particularly the delay with maximizing/unmaximizing, I was told that it was more likely because Compiz changed the way it transfers info from video card to memory when it comes to window management (maximizing in this case). Don't know if it's true or not, but they are the professionals here so I'm inclined to believe them, and it wouldn't be the first time Compiz breaks/changes things.

      Comment


      • #33
        For me the same 1-2 second lag appears when ANY compositor is used.
        Compiz under both gnome and kde, metacity compositor under gnome and KWin under kde all show the same behavior.
        Everything works fine without compositing - though kde is pretty sluggish anyway.

        Add ati's history with linux and somehow I doubt this isn't all caused by the driver.

        Comment


        • #34
          The Metacity and the Xfwm compositors don't exhibit any of the delay for me , be it fglrx or open drivers (those are not hardware accelerated anyway). The Kwin composite manager has always been sluggish with fglrx, so that could be a different problem (specially since even open drivers can be sluggish). Ubuntu Compiz saw several fglrx performance fixes by the end of Intrepid, most of the "regressions" being a Jaunty thing, so a problem with the Compiz version in Jaunty is not such an ubeliavable thing.

          Comment


          • #35
            Originally posted by Melcar View Post
            The Metacity and the Xfwm compositors don't exhibit any of the delay for me , be it fglrx or open drivers (those are not hardware accelerated anyway). The Kwin composite manager has always been sluggish with fglrx, so that could be a different problem (specially since even open drivers can be sluggish). Ubuntu Compiz saw several fglrx performance fixes by the end of Intrepid, most of the "regressions" being a Jaunty thing, so a problem with the Compiz version in Jaunty is not such an ubeliavable thing.
            I have had beautiful performance in kde with composite. So I doubt there is anything wrong with kde 4.2.2's performance. Also I doubt its the fglrx, which worked perfect in intrepid. Actually Fedora 11 with the open source driver works also perfect with kde 4.2.2. My problem persist with fglrx and jaunty.

            Comment


            • #36
              Ok this definitely a performance problem in fglrx it appeared in 9.4 maybe earlier considering X.org patches in Ubuntu. This one has already been stated. theres always been regressions left and right with fglrx releases at one point I had no video acceleration. Somewhere between 8.08 8.11 was the best release for Hardy.
              In Intrepid there was a huge memory leak that popped up from using fglrx and It existed til 9.2 think it still exist now, that causes performances degradation etc. The OSS Driver doesn't have that type of degradation so I know it was a fglrx problem.

              Now for the open drivers the 64 bit versions actually perform far better than 32bit. Odd as it may be, 32 bit open source drivers Wobbly windows was choppy and very slow, and 64 bit compiled I can have wobbly windows although slowish it wasn't in anyway choppy.

              Had to switch to unready Open Source Drivers, can't have multi user acceleration with them or OpenGL2 as of yet, because ATI dropped support for my x1200, the r690v, in fglrx, something i bought less than two years ago and I think their still being sold in stores, pretty much forced me to the OSS Drivers now, I was hoping to jump to them next year when they were going to be ready, ATI just pushed me about 7-10 months early.

              So thats how i came to discover 64 bit OSS drivers were faster than 32bit, switched my system from 32bit Intrepid -> 32bit Jaunty Upgrade -> 64bit Jaunty Clean install with ext4 system and ext3 /home speedier than Intrepid in most cases, as the OSS drivers do 2D better. At least right now the OSS Drivers are enough to get by with alright performance in most cases, without any unprepared regressions that come about from fglrx.

              At least ATI helps in the development of the OSS drivers and I thank them for doing that.
              Last edited by TheWind; 30 April 2009, 06:49 PM.

              Comment


              • #37
                imo... i have been suffering from this 1-2sec delays ever since fglrx has aiglx support... oh well... just told myself to live with it till it gets better but NOOOOO.... i'm stil having that 1-2 sec delay...

                runnning gentoo btw~~ ^^

                i remember reading a thread from compiz forums and how there seem to be a missing implementation... something like blt_mmx_something so it fell back to a software implementation instead of being hardware accelerated.... *disclaimer* i'm recalling it by memory....

                hopefully the binary drivers improve(i'm not really THAT hopeful) or the radeon drivers support 3d acceleration on my card.... r635(hd 3650) (more hopeful....)

                Comment


                • #38
                  The issue was discussed in https://bugs.launchpad.net/ubuntu/+s...er/+bug/351186 and it looks like they found the patch in question. There's also a PPA which I just tried and resizing and alt-tabbing is as fast as it was before.

                  Comment


                  • #39
                    This fix, indeed, fixes the lagging issue, and I haven't really noticed any corrupt graphics.

                    However, there is still a huge memory leak that occurs when running with effects enabled. Here's the bug report: https://bugs.edge.launchpad.net/ubun...er/+bug/372345

                    Even after enabling the patch, Xorg still continuously leaks memory to the point you will either have to restart X or your system after you have opened or close several applications over an extended period. Don't play with the maximize/restore button, either.

                    Fix one thing and now we have to worry about something else.

                    Comment


                    • #40
                      hmmm... so maybe i recalled correctly... there is missing bitmap acceleration in the fglrx drivers? gosh... can some dev comment on it to shed some light?

                      Comment

                      Working...
                      X