Closed Bug 594319 Opened 14 years ago Closed 13 years ago

Performance regression: canvas slow in Firefox 4 on Linux with X servers older than 1.7

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: LpSolit, Assigned: karlt)

References

(
URL
)

Details

(Keywords: perf, regression) 

As discussed on IRC with Paul, here are my results:

Test page: http://demos.hacks.mozilla.org/openweb/HWACCEL/

Mandriva Linux 2010.0
Linux localhost 2.6.31.13-server-1mnb #1 SMP Tue Apr 27 21:42:56 EDT 2010 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GNU/Linux

Graphic card: ‎nVidia Corporation, ‎G84 [GeForce 8600 GT]

Results, with a new profile, no extension (besides the default Feedback one, with Fx4):

Fx3.6.9: 59 FPS
Fx4.0b4:  7 FPS
Fx4.0b5:  8 FPS
Fx4.0b6:  8 FPS

Fx4.0 is much slower than 3.6.9!
IMO, a blocker. It's so slow.
blocking2.0: --- → ?
Summary: Hardware acceleration inefficient on Linux (8 FPS!) → Performance regression: canvas slow on Linux in Firefox 4
We don't have any hardware acceleration on Linux by default (past whatever RENDER might do for us).  Did you enable some sort of non-default options?

Can you figure out (using nightlies) when things regressed for you here?
Some other people reported to me that this test is slower on Firefox 4 on Linux.

Frédéric, can you see which nightly caused this regression?
(In reply to comment #2)
> Did you enable some sort of non-default options?

Not that I know of. I used a new profile.


> Can you figure out (using nightlies) when things regressed for you here?

I tried with beta 2, and the problem was already there. Didn't try with older versions.
OK, I did some more testing, and the problem occurs between 3.7a4 and 3.7a5. For alpha 4 and older, I get > 60 FPS. For alpha 5 and newer: < 10 FPS.
OK, I narrowed it down to a 24 hours window:

Fast (70 FPS): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre

Slow (8 FPS): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100519 Minefield/3.7a5pre
Can you post the hg revisions for those in about:buildconfig
Maybe caused by bug 565875? CC'ing roc.
Keywords: regression
On Linux, I'd think bug 547924 is more likely to be the problem...
Especially because the OGL stuff is not on by default.
Seems like http://hg.mozilla.org/mozilla-central/rev/e328183c0602 could be the cause. Bug 422179 should fix it.
Keywords: regression
Blocks: 547924
Depends on: 422179
Keywords: regression
Frédéric can you test this again when tomorrow's nightly build is available, please?

And please also indicate X server and driver versions:
"xdpyinfo | grep version" and "glxinfo | grep OpenGL"
(In reply to comment #13)
> Frédéric can you test this again when tomorrow's nightly build is available,
> please?

OK, will do this week-end.


> And please also indicate X server and driver versions:
> "xdpyinfo | grep version" and "glxinfo | grep OpenGL"

# xdpyinfo | grep version
version number:    11.0
X.Org version: 1.6.5

# glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8600 GT/PCI/SSE2
OpenGL version string: 3.3.0 NVIDIA 256.53
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL extensions:
(In reply to comment #14)
> X.Org version: 1.6.5

OK, thanks.  So the issue is probably cairo doing fallback for EXTEND_PAD introduced in bug 547924 because cairo thinks the server (older than 1.7) will get EXTEND_PAD wrong.

Bug 422179 shouldn't have made any difference with servers older than 1.7.
No longer depends on: 422179
Keywords: perf
Summary: Performance regression: canvas slow on Linux in Firefox 4 → Performance regression: canvas slow in Firefox 4 on Linux with servers older than 1.7
So the solution for Frédéric is to update his X server :-)
(In reply to comment #16)
> So the solution for Frédéric is to update his X server :-)

Hey, Mandriva Linux 2010.0 has been released on 2009/11/03, and you say it's already too old? ;)
That's normal for Linux land.  First they ship with not necessarily up-to-date stuff, then they rapidly change things.  The net result, in my experience, is that anything older than about 6 months is more or less unsupported...  ;)

More seriously, it's too old to have a correctly working X server.  Yay Xorg.  :(
Really, the root of the problem is that many years ago XRender was designed with a default extend mode of NONE, which not what apps want but close enough for people to not notice or care about the bugs.
In that case, is there no way for Fx4 to fallback to its 3.6 behavior when the X server is older than 1.7? I hope I'm not the only one to run a distro which is one year old.
> In that case, is there no way for Fx4 to fallback to its 3.6 behavior 

You mean the one where we paint faster but wrong?
How wrong is that? Else I guess this bug will end as wontfix, right?
Well, you're basically suggesting backing out the fix for bug 547924, right?
I'm not suggesting anything. I'm not a Core dev.
Well, that's what falling back to the 3.6 behavior would be... reintroducing bug 547924.
(In reply to comment #19)
> Really, the root of the problem is that many years ago XRender was designed
> with a default extend mode of NONE
Then might modification of xorg.conf will solve the problem?
(In reply to comment #26)
> Then might modification of xorg.conf will solve the problem?

Nothing that simple, I'm afraid.

(In reply to comment #20)
> ... when the X server is older than 1.7?

The xserver 1.7 check in cairo is not a precise check for correct functionality.
There were bugs in pixman and in graphics drivers.  Because pixman is likely to get used sometimes with free drivers, a server version check is probably a reasonable test.

If the NVIDIA driver never falls back to using pixman and does not have RepeadPad bugs, then maybe a check for NVIDIA drivers could be added.
However, I don't know and I can't read the source to find out whether these drivers might fall back to pixman.

Also, time is most likely better spent making sure things work well on current and future systems (even though "current" here means very recent).
We can be wrong on old, slow X servers. We should be fast everywhere else. Can't we use the same test we use for drawing images?
Assignee: nobody → karlt
blocking2.0: ? → betaN+
(In reply to comment #28)
> Can't we use the same test we use for drawing images?

That's probably an option.
(In reply to comment #27)
> If the NVIDIA driver never falls back to using pixman and does not have
> RepeadPad bugs, then maybe a check for NVIDIA drivers could be added.

<karlt> jorgenpt: do you happen to know whether the NVIDIA drivers ever fallback to pixman for software compositing (or whether they have their own software renderer)?
<jorgenpt> karlt: If it's needed we fall back to whatever was registered for the operation before we installed our implementation, yes.
<jorgenpt> karlt: You can force unaccelerated rendering using Option "RenderAccel" "0".
This occurs with the latest HG code and linux, radeon driver. flash is much faster in 3.6 than 4.0b8/9
Notlost, this bug is about canvas.  A regression in Flash performance is probably unrelated and deserves it's own bug.  Can you file with details of driver/server version and example URLs, please?
I get the same issue with Firefox 4.0 b7 on current Debian testing:

glxinfo | grep string

server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6200/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 195.36.24
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler

Using X.Org 1.7.7 and libcairo2 1.8.10-6
blocking2.0: betaN+ → -
Same here with Firefox 4b8, Ubuntu 10.10 (32-bit).

glxinfo | grep string output:
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce Go 6150/PCI/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 260.19.06
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler

X server 1.9.0, system libcairo2 version 1.10.0-1ubuntu3
Do we know that this is definitely caused by extend_pad issues?  For those of you seeing the problems, try going to about:config and setting layers.accelerate-none to true; then restart and try again.
(In reply to comment #35)
> you seeing the problems, try going to about:config and setting
> layers.accelerate-none to true; then restart and try again.

This doesn't help. Fx4.0b8: 9 FPS with this param being true or false.
http://lists.freedesktop.org/archives/nouveau/2010-October/006665.html
says "nv40+ will be fine, older cards can't repeat[pad] NPOT textures", but AIUI all cards reported here are nv40+ anyway.

Comment 33 and 34 are newer servers and so not covered by this bug.
It would be helpful to have a regression range on those systems (and a different bug report if the regression range is not the same).
X.Org 1.7.5+6ubuntu3, libcairo2 1.10.0-1ubuntu3, test: 5 FPS.

$ glxinfo | grep string
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce Go 6100/PCI/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 260.19.06
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler
...and the last nightly.
> IMO, a blocker. It's so slow.

+1. On forums, you can read that lots of people has this problem.
Summary: Performance regression: canvas slow in Firefox 4 on Linux with servers older than 1.7 → Performance regression: canvas slow in Firefox 4 on Linux with X servers older than 1.7
Going forward EXTEND_NONE is going away and I doubt we'll be investing a lot in this. Updating the X server is the right thing to do.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.