[173.08]2D is very slow

[bearoso]

Originally Posted by Cimi

173.08 finally fixes rendering problems with transparency (see my transparent engine): http://arstechnica.com/articles/cult...ting-gtk.ars/3

So ok, fix speed but I think that the correct rendering we now achieved is a way more important.

EDIT:
not at all, I have some rendering problems too

Cimi, I believe your scrolling issue is related to http://www.nvnews.net/vbulletin/showthread.php?t=104822, a race bug.

Based on the appearance of your screenshots, it looks like the scrolling window is getting a partially drawn state from TFP (during the overdraw from the past frame to the current frame). In the linked thread, you'll notice that since 169.07 the problem has been funky colors, but the problem originally represented itself similar to the scroll windows, as partially drawn titlebars.
(The funky colors seem to be a partially-transferred planar image, while the obviously half-drawn images must be transferred as packed.)

[Cimi]

Originally Posted by bearoso

Cimi, I believe your scrolling issue is related to http://www.nvnews.net/vbulletin/showthread.php?t=104822, a race bug.

Based on the appearance of your screenshots, it looks like the scrolling window is getting a partially drawn state from TFP (during the overdraw from the past frame to the current frame). In the linked thread, you'll notice that since 169.07 the problem has been funky colors, but the problem originally represented itself similar to the scroll windows, as partially drawn titlebars.
(The funky colors seem to be a partially-transferred planar image, while the obviously half-drawn images must be transferred as packed.)

you mean this one? http://www.nvnews.net/vbulletin/showthread.php?t=107825

notice that it was always present, at least even for the 96.xx releases

[bearoso]

Originally Posted by Cimi

you mean this one? http://www.nvnews.net/vbulletin/showthread.php?t=107825

notice that it was always present, at least even for the 96.xx releases

Yeah, the same one. Since its introduction, the nvidia texture-from-pixmap implementation has never had a 100% success rating for downloading from the pixmap. It's definitely done asynchronously, and the timing has had a tendency to be incorrect.

[Cimi]

Originally Posted by bearoso

Yeah, the same one. Since its introduction, the nvidia texture-from-pixmap implementation has never had a 100% success rating for downloading from the pixmap. It's definitely done asynchronously, and the timing has had a tendency to be incorrect.

but this happens also when not using tfp, for example using metacity with composite (trough xrender then)...

[bearoso]

Originally Posted by Cimi

but this happens also when not using tfp, for example using metacity with composite (trough xrender then)...

That's interesting info. I assumed it was associated with the tfp transfer not waiting. Maybe the problem is that some accelerated drawing operations are being reported done when they're not. It might also have to do simply with the transfer of the pixmap from system to video memory, which both xrender and tfp handle. I'm still confident that the issues are related, though, with partially drawn RGBA pixmaps being composited. It's very unfortunate that nvidia developers haven't been able to reproduce this yet.

[czarnyckm]

Originally Posted by drzoo2

The sky textures look nice now.....no more bars. Now if you can fix the wicked, wicked shuttering, we'd have a playable game on my 8800GT.

You should try to add :

...
Section "Device"
        # This option must be either undeclared or
        # false, in order to avoid periodic short-term
        # freezes on beryl and other OpenGL intensive
        # programs
        Option      "UseEvents"         "false"
...

in /etc/X11/xorg.conf. It fixed similar problem with Google Earth or ETQW on KDE without compiz.

See also HOWTO nVidia GL Desktop Effects

czarnyckm

[drzoo2]

Originally Posted by czarnyckm

You should try to add :

...
Section "Device"
        # This option must be either undeclared or
        # false, in order to avoid periodic short-term
        # freezes on beryl and other OpenGL intensive
        # programs
        Option      "UseEvents"         "false"
...

in /etc/X11/xorg.conf. It fixed similar problem with Google Earth or ETQW on KDE without compiz.

See also HOWTO nVidia GL Desktop Effects

czarnyckm

Thanks!
I'll test it out.

z

[tbyte]

Guys, I'm happy to inform You that nVidia driver suck in 2D on FreeBSD in exactly the same way (both drivers share about 90% of their code i think). And it's stranger that Xorg's nvidia driver "nv" is faster in 2D than nvidia's own driver which is pathetic . And it's bearable on 8800GTS at home but on 6200 at work sometimes I have ideas of smashing the PC against the wall many many many many times until it becomes unrecognizable piece of metal . And worst of all , their older drivers worked fine, e.g 8178, and some version after that they ****ed up something veeeery bad. That 8178 driver worked fast even on 6200 in 2D and 3D, current drivers are some kind of a joke in 2D (but still ok in 3D). I wander, can't nVidia's developers just find what have changed from that 8178 to let say 8774 and fix it. I was using 8178 untill Xorg stopped working with it some months ago , hoping that they'll listen to all of us saying their drivers got crappy 2D performance, but NADA, NO. I may sound really pissed , but I don't sound as pissed as I really am. I'm much much more pissed than I sound

[ollebull]

I'm having the same problem as some of the users have listed above, slow 2D acceleration. Not painfully slow, but noticeable slow in desktop use. And I'm starting to regret my purchase of a laptop with a nvidia graphic card, hoping to achieve some extra power under the hood. But my old 6600GT outruns my new 8600M GT by far, It's much more responsive in desktop use, both while using compiz and without. I hope nvidia will be able to fix this very soon, it's really starting to annoy me.

[Gregor A.]

Originally Posted by ollebull

...but noticeable slow in desktop use.
I hope nvidia will be able to fix this very soon, it's really starting to annoy me.

Yes, we hope this since months.
I think NVIDIA has designed the NEW 8xxx and 9xxx hardware only for DIRECTX 10 and not for OpenGL or 2D acceleration.

I didn't believe that a new driver can solve the problem.

My big hope is INTEL or ATI...

[pawels133]

Originally Posted by Gregor A.

Yes, we hope this since months.
I think NVIDIA has designed the NEW 8xxx and 9xxx hardware only for DIRECTX 10 and not for OpenGL or 2D acceleration.

I didn't believe that a new driver can solve the problem.

My big hope is INTEL or ATI...

My GF6800 is painfully slow with their binary crap, so there's hope that they just broke drivers. Yeah, there are really fascinating things going with ATI OS drivers. UT2K4 is working with them!

[ollebull]

Originally Posted by Gregor A.

Yes, we hope this since months.
I think NVIDIA has designed the NEW 8xxx and 9xxx hardware only for DIRECTX 10 and not for OpenGL or 2D acceleration.

I didn't believe that a new driver can solve the problem.

My big hope is INTEL or ATI...

Yeah, I have too been waiting long, since I bought the laptop (half a year ago I think)
Has nvidia identified the problem, why is it taking such long time to correct? The Windows driver doesn't have the performance problem with 2D acceleration with 8xxx-cards what I know, so what is stopping you from getting it to perform well under Linux?

I think that AMD/ATI initiative with releasing specifications and developing their driver open source was a great step in the right direction, hope nvidia will go for this too.