Catalyst 9.8 - "compiz default maximize" = effect significant lag

[kUrb1a]

Man I just can't wrap my mind that fglrx really,STILL,uses XAA acceleration for their driver.
Are they gonna update that in future releases or are we have to wait for that like it was with aiglx,and what the hell were they thinking with XAA !?

[energyman]

Interesting tidbit: nvidia drivers seem to do something similar to the "no backfill" patch, where some windows show garbage for a split second when maximized.

Fglrx without "no backfill" = no garbage but slow maximization
Fglrx with "no backfill" = garbage for a split second but fast maximization
Nvidia without "no backfill" = garbage for a split secont but fast maximization

I see behavior this on both a Quadro NVS135M (190.xx drivers) and a 9500GT (185.xx drivers). Obviously, I cannot be 100% certain, but it seems that nvidia drivers have some kind of hack for the slow maximization issue.

nvidia just replace a lot of X infrastructure in their drivers

[energyman]

Man I just can't wrap my mind that fglrx really,STILL,uses XAA acceleration for their driver.
Are they gonna update that in future releases or are we have to wait for that like it was with aiglx,and what the hell were they thinking with XAA !?

well? it works? it is proven and stable? workstation customers prefer stable over the lastest cool and unproven buzz word of the moment?

seriously, if you did not look into xorg.0.log you would not know the difference.

[kUrb1a]

I guess you are wright.It's just that with every release(new and old ones) i have to to read long posts in forums how fglrx driver is bad and how ati just doesn't give a damn and to hear now that drive uses XAA over EXA and that might be the reason for the problem since i installed my first Linux Distro just makes me angry right now but i guess ati knows better than me,...sooo,...keep up the good work ati.

[nanonyme]

The "ATi doesn't care" things you read all around are mostly just trolling. You can safely ignore those. There's problems with fglx but ATi both continues to develop it and support the opensource driver projects which are gradually getting considerably far. (the impact of the cooperation on the support for new cards probably being bigger though)

[BlackStar]

Is fglrx really using XAA for acceleration? How do the Textured2D, TexturedXRender and TexturedVideo options interact with this?

In any case, fglrx offers good 2d performance nowadays even with Compiz (just a year ago it didn't) and the open drivers are even better. My 9500GT and Quadro NVS135M from nvidia feel quite a bit slower, anyway.

That said, my old 7600GS offered the absolutely best performance in 2d, but things regressed badly with the release of the 8000-series.

[bridgman]

Not sure where the "ATI says it's X's fault" comment is coming from. I said that the slowdown resulted from an X *change* (backing out a performance patch which had been there for years), which is not the same thing.

The question of "whose fault" is a philosophical issue which will probably never get answered (and nobody cares about the answer), since it relates to a portion of the X spec which may not make sense with a compositor (as I understand it). With the patch one bad thing happens (some recent drivers display uninitialized memory), without the patch a different bad thing happens (a large and un-necessary copy from vram to system ram).

The most likely solution is that we will paper over the problem like everyone else by accelerating the "large and un-necessary copy" so you don't get a big delay, but there are some potentially cleaner solutions (ie fixing the underlying problem) that we are looking into as well.

[smitty3268]

I hope something happens soon, because this is one of those serious bugs that cause non-Linux users to do a double take and ask why you put up with stuff like this when you could use windows instead. And it's been around for quite a while now.

Looking at the patch that seems to fix it (http://blog.jasondonenfeld.com/190) could a quick workaround in the xserver just be to fill in that pixmap with zeroes to get rid of the random backfill without the slow copy operation? I seem to remember the point was to fix possible security issues, which this would do even though it might be ugly. Or was this rejected by the x developers because they figured the operations involved should be accelerated and the issue is with AMD?

[fermulator]

Good day!

Do we have any progress on this issue? Is this a workaround that users can perform in the meantime as to avoid the terrible maximize lag? (It's quite frustrating)

[energyman]

Good day!

Do we have any progress on this issue? Is this a workaround that users can perform in the meantime as to avoid the terrible maximize lag? (It's quite frustrating)

yes, install an unbroken X server with fedora_dont_backfill_bg_none.patch

X flies afterwards.

There are patched debs for kubuntu and an ebuild for gentoo. For the others:

google