Closed Bug 575871 Opened 15 years ago Closed 13 years ago

Canvas is slower than in 3.7!

Categories

(Core :: Graphics, defect)

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

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: donrhummy, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: ietestdrive)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre When running this page: http://ie.microsoft.com/testdrive/Performance/01FlyingImages/Default.html Firefox 3.6.x is poor but 3.7a5 was pretty good. However, 4.0beta is now poor again! No idea what happened in between. Reproducible: Always Steps to Reproduce: 1.Run the web page included or any of the canvas tests by microsoft on Linux Actual Results: Runs at very few fps. Expected Results: Run at a decent fps (say 38 or so, but it runs at 20).
This isn't a webgl test. Do you have d2d enabled in the 4.0beta build? Did you have it enabled in the 3.7a5 build?
Component: Canvas: WebGL → Graphics
QA Contact: canvas.webgl → thebes
How do I enable that?
Set the "mozilla.widget.render-mode" preference to 6 in about:config.
Did that and it's still slower! Weird.
OK, just to be sure, I ran another test (with the above web page): 1. Used Firefox Beta 4, got 18-25 fps (varied) 2. Closed beta 4 3. Opened Firefox 3.7a5, got 60 fps!! This happens everytime.
OK, do you want to try nightlies between those two to try to pin down when the problem appeared?
(In reply to comment #6) > OK, do you want to try nightlies between those two to try to pin down when the > problem appeared? Sure, where do I find the nightlies? When I look here (see below) it's not 100% clear which ones I should be trying. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ For example, do i try the tracemonkey folders? Or electrolysis? or mozilla-central? 2010-06-17-03-mozilla-central/ 2010-06-17-03-tracemonkey/ 2010-06-17-04-electrolysis/ Thanks.
You want the mozilla-central nightlies. Thanks for looking into this!
(In reply to comment #3) > Set the "mozilla.widget.render-mode" preference to 6 in about:config. Huge important note: you have to also turn on DirectWrite for Direct2D to work. To do this, you need to set the "gfx.font_rendering.directwrite.enabled" preference to true in about:config.
OK, after doing testing on a ton of nightlies, I believe I've got a better handle on the issue: * With 3.6 and 3.7a5 you did not need to set render-mode or directwrite (they could be -1 and false) * With the later versions (4.0b) if those are not set BEFORE startup (i.e. set them, then restart) it runs VERY poorly Any idea why those are now required to get the 60 fps? Why weren't they before? Will they be set by default when 4.0 comes out? And why aren't they set in 4.0b?
What was the last nightly that was fast without the prefs set, and the first one that was slow without the prefs? Especially, what was the build id url in about:buildconfig for each of those?
Whiteboard: ietestdrive
(In reply to comment #11) > What was the last nightly that was fast without the prefs set, and the first > one that was slow without the prefs? Especially, what was the build id url in > about:buildconfig for each of those? Sorry for the long wait, but I was pretty busy. I finall had time to go through this and I found it!! The last FAST/good build was from august 12th: (From about:buildConfig) Built from http://hg.mozilla.org/mozilla-central/rev/cdfff833edf9 The first SLOW/bad build was from August 14th: (From about:buildConfig) Built from http://hg.mozilla.org/mozilla-central/rev/656d99ca089c So whatever changes were made in the build "656d99ca089c" are causing the slow canvas!
Pushlog for that changeset range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cdfff833edf9&tochange=656d99ca089c The "enable d2d by default" change is in there. But I just realized this bug was reported on Linux, right? If so, then maybe the units changes affected this? roc, any idea?
blocking2.0: --- → ?
Maybe some of the image changes?
I think this might be an appropriate place to comment. I've been looking for the right bug to post this on so I don't duplicate efforts but there are a number of canvas bugs going on... I noticed in Beta 6 using http://www.canvasdemos.com/2010/07/27/canvas-colour-cycling/ (this is a one off link from the actual page, but I wanted those working on this to see the comments from the author) that the fps started off low and then cranked up. On pre7 (0920), the fps started near 40 but then would fall back near 30 after a short whiles (less than minute). On pre7 (0921), the fps is around 40, was seeing 37 to absolute peak of 41. Occasionally it would drop to 31 and then it would cycle back up. When I Max it Fx drops to 8fps for a few seconds and then climbs back up to settle high 20s to low 30s. It's also a little jerky expanding. Opera seems to be pretty well on this demo (high 40s iirc, sorry writing this from memory off-hand). The higher fps isn't what concerns me as that is was consistent while Fx seems to be fluctuating quite a bit.. Given it was 47fps it would hover between 46-47fps, maybe occasionally scratching 45. Ten fps is a fair bit of fluctuation. There's a number of other canvas demos at that site, but this one is useful in gives us the fps as a number we can compare (vs just what we see). There's also different scenes, but for simplicity I use the default one to compare. Opera does horrible on IE Tests. I don't know how reflective that is of canvas or if it is even truly Canvas. But I tried a few other demos and they seem to work fair on them. The reason I use Opera as an example is it seems to do well with Canvas and gives me something to compare against about how it should function. Chrome gives low fps, and Safari coughs. I'm comparing things just about every evening with a new nightly so I be happy to share what I see if you believe that will help.
I can't block on this unless it gets confirmed. Once someone confirms it, please nominate it for blocking again.
blocking2.0: ? → ---
Hmm. Reporter, what are your exact steps for the flying images test? Note that the exact mouse position in the window matters, as far as I can see... I get numbers between 4fps and 60fps just based on that.
(In reply to comment #17) > Hmm. Reporter, what are your exact steps for the flying images test? Note > that the exact mouse position in the window matters, as far as I can see... I > get numbers between 4fps and 60fps just based on that. In both cases, I put the mouse over the images and then I move it left-right and then up-down. So both have the same "environment" relative to the mouse. Yet, in 3.7, I get 60fps no matter what, whereas the later slow builds never get over about 20 fps or so.
With how many images?
I'm getting 60fps on this demo no matter what unless i zoom in and I still get over 50 fps easily. If I increase # of images lowest I hit is 23fps at max of 256 images AND zoomed in. This is checking on today's pre7 nightly build (0928). My chipset: Intel Core 2 Duo Processor T7250 NVIDIA GeForce 8400M GS Windows Vista Maybe your chipset?
David, what Vista with hardware acceleration does is not all that relevant to what Linux (which this bug is reported against) does, where graphics performance is concerned.
(In reply to comment #19) > With how many images? Just the default 36 images.
OK. So at least on my machine (Mac, recent hardware) I'm not seeing the problem.... So maybe it's Linux-specific or needs a slower machine to see the drop below 60fps. If I did some Linux builds to bisect the regression range, would you be willing to try them to see which ones are fast and which are slow? It'd be slow turnaround time on try server (figure a day per build), but binary search shouldn't take too many builds.
(In reply to comment #23) > OK. So at least on my machine (Mac, recent hardware) I'm not seeing the > problem.... So maybe it's Linux-specific or needs a slower machine to see the > drop below 60fps. > > If I did some Linux builds to bisect the regression range, would you be willing > to try them to see which ones are fast and which are slow? It'd be slow > turnaround time on try server (figure a day per build), but binary search > shouldn't take too many builds. Sure, no problem, send them along! :)
(In reply to comment #13) > Pushlog for that changeset range: > > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cdfff833edf9&tochange=656d99ca089c Bug 572680 is in there, which apparently caused an image drawing performance regression, see bug 600476.
And if you'd like we can try testing the revisions around bug 572680 next.
(In reply to comment #26) > OK. > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-9d0cf519e946/tryserver-linux/firefox-4.0b4pre.en-US.linux-i686.tar.bz2 > is a build from essentially revision 255b19177dd. How do things look in that > build? It works perfectly. Consistent 60fps.
(In reply to comment #29) > What about > http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-53d1073f8712/tryserver-linux/firefox-4.0b4pre.en-US.linux-i686.tar.bz2 > (built essentially from revision 5deb7e7751d8)? Also fine. Ran mostly at 60fps, with a few seconds at 54 fps, but I think that was just the computer running something. It stayed at 60fps after that.
(In reply to comment #31) > Alright. What about > http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-fc00712bbd40/tryserver-linux/firefox-4.0b4pre.en-US.linux-i686.tar.bz2 > (built essentially from revision 17f4064c1d23)? Also fine.
ping?
(In reply to comment #36) > ping? Sorry I haven't replied. We have a bit of a problem. My hard drive died and I've been dealing with that, restoring from backup, etc. I've had to replace it and I decided to upgrade my OS to the newest version and now I'm not able to replicate the issue anymore. Under my previous OS the issue occurred 100% of the time but now I can't get it to occur. I do have another computer with the previous version of the OS and I'll give it a try there. I'll let you know if I can replicate it there. Sorry, I hope there's some way to figure out what the change was if I can't replicate it.
Gotta love computers. ;) OK, let me know how things go on the other computer...
For me firefox is simply slower than chromium 9 with accelerated 2D canvas enabled. I tried 10-08 nighlty and it is as slow as today one. Fish ie tank: minefield 12 fps chromium 40 fps. With this test http://demos.hacks.mozilla.org/openweb/HWACCEL/ miefield 6-10 fps chrome 35 fps Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101025 Firefox/4.0b8pre
Zio, you're under linux. ATI card + fgrlx? 'cause, I get ridiculously high speeds on my intel and nvidia cards, but slower speeds on fglrx, only slightly improved (about 25%) by layers.accelerate-all. Mozilla dudes said it was significantly slower xrender under ATI, or something like that. BTW, on my intel card, opposite effect. layers.accelerate-all slowed the demos to a crawl, but blazing fast using (presumably) X11's rendering.
Chrome is using GL, we're using XRender. So if drivers accelerate one well, but not the other, one browser will be fast and the other won't.
(In reply to comment #41) > Chrome is using GL, we're using XRender. So if drivers accelerate one well, but > not the other, one browser will be fast and the other won't. Got it, anyway I can't reproduce this regression.
(In reply to comment #40) > Zio, you're under linux. > ATI card + fgrlx? > > 'cause, I get ridiculously high speeds on my intel and nvidia cards, but slower > speeds on fglrx, only slightly improved (about 25%) by layers.accelerate-all. > > Mozilla dudes said it was significantly slower xrender under ATI, or something > like that. > > BTW, on my intel card, opposite effect. layers.accelerate-all slowed the demos > to a crawl, but blazing fast using (presumably) X11's rendering. No, I have a GeForce 6150SE nForce 430 with 260.19.12 drivers and for me layers.accelerate-all slows the demos but slightly increases rendering speed (could be a placebo effect, I don't know).
This is almost certainly due to Xorg < 1.7, which we've decided we're not too concerned about any more.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Hmmm. Pretty darn sure it is still happening in Xorg 1.7. Let me go get that laptop and check. If it does, shall ask someone to reopen. :)
Heeey Joe. Well, I can't test http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/08/2010-08-12-03-mozilla-central/ (the last known good of the reporter) since it simply segfaults over here now. But FWIW, I get 25 FPS (if I strain it by using 256 images rotating exactly so an image sweeps across the whole display) in FF3.6, and 13 FPS in FF11a. But, that could possibly be same as I get in HWACCEL in bug #602380. Since I can't seem to run that nightly, I can't tell if that build did better than current builds :)
You need to log in before you can comment on or make changes to this bug.