Open Bug 932334 Opened 12 years ago Updated 2 years ago

Firefox runs fluid simulation at about 2/3rds of Chrome speed with layers.acceleration.force-enabled set to true in Linux

Categories

(Core :: Graphics: Canvas2D, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: bugs, Unassigned)

References

()

Details

Testing Firefox nightly against Chromium 28. Chrome ran the simulation at about 650 steps per second, Firefox ran it at about 440 steps per second. The author noted this last summer, and has a chart here: http://dvschroeder.blogspot.com/2013/07/java-vs-javascript-vs-python.html
Flags: needinfo?(jdemooij)
Ok, after I tried a clean profile, I got almost identical results in Chrome and Firefox under Linux. On my OSX mac mini 2 I got 650 steps per second in Firefox Nightly, 290 in Safari 7, and 550 in Chrome 30. I jumped to conclusions since my results were similar to his graph. My guess is that it was in part due to running SPS on the Firefox profile. The other thing that is odd is that after setting layers acceleration force-enabled in the clean profile, my steps per second dropped from 605 to 466... That's rather odd since usually layers acceleration improves performance on these canvas demos which is why I had it enabled in the other profile. Anyway, definitely not a javascript problem. Possibly some linux canvas weirdness going on.
Component: JavaScript Engine → Graphics: Layers
Summary: Firefox runs fluid simulation at about 2/3rds of Chrome speed. → Firefox runs fluid simulation at about 2/3rds of Chrome speed with layers.acceleration.force-enabled set to true in Linux
As far as I know canvas is not hardware accelerated on Linux so I don't think layers acceleration will improve performances there.
WRT that last comment, which I found really odd, I did run into: bug #606855 which was discussing Firefox running slower w/ layers acceleration. It says it was fixed though.
I *am* running the open source driver (since fglrx leaked and eventually crashed after running for a while) which is no speed demon. $ DISPLAY=:0 vblank_mode=0 glxgears 8400 frames in 5.0 seconds = 1679.895 FPS 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 XT [Radeon HD 4670] [ 102.720] (II) Module radeon: vendor="X.Org Foundation" [ 102.720] compiled for 1.13.3, module version = 7.1.0 So, here's some combinations... azure set to skia, layers acceleration force enabled true: 515 steps per second azure set to skia, layers acceleration force enabled false: 460 steps per second azure set to cairo, layers acceleration force enabled true: 440 steps per second azure set to cairo, layers acceleration force enabled false: 580 steps per second azure disabled, layers acceleration force enabled true: 440 steps per second azure disabled, layers acceleration force enabled false: 570 steps per second So the fast ones are no azure or azure+cairo with no layers accel or azure+skia+layers accel And the slow ones are azure+skia with no layers accel or no azure or azure + cairo with no layers accel. Given that I think cairo is pretty much the default, azure or no, that seems to imply skia + layers accel = good, cairo = layers accel = bad...
When you use accelerated layers, you generally paint content on the CPU and upload it to a texture that you can then use for compositing. If the content did not change, compositing again is cheap because you don't need to upload the pixels to the GL texture a second time. Canvas benchmark stuff (and games), however typically modify the content as much as possible so you need to go through expensive texture uploads a lot, so you trade fast compositing with slow texture uploads (that's what I was referring in my previous comment). If your canvas uses the GPU, then the content it produces is already on the GPU so you don't have to suffer the cost of texture uploads, and that's where you can expect big speedups if you are compositing on the GPU content that changes a lot. There are also low level APIs that let you map a buffer on the CPU, paint to it and get fast paths to turn it into a GL texture but we don't use that on Linux (yet).
Flags: needinfo?(jdemooij)
Severity: normal → S3

The linux graphics system has changed multiple times since this was filed and I wouldn't be able to reproduce the test system even if I wanted to.

That said. I tested in Firefox nightly on my current machine, and Chromium Stable yielded 490 frames per second on 320x120, Firefox, 350 per second.

I don't know if the root causes are the same as back then, but it's interesting the ratio is still about ⅔rds..

So, not going to close this one 😃

Component: Graphics: Layers → Graphics: Canvas2D
You need to log in before you can comment on or make changes to this bug.