At least on Windows, image painting takes a lot of CPU time to display when using an NVidia graphics card compared to an ATI graphics card. This really shows up with animated objects. I recall some differences in Blit functions when a background tiling bug was fixed... Anyway, this difference is not present in IE, and may be the major cause of bugs like bug 86319 and bug 87808. We need to find out what code is causing the difference, especially since NVidia has the largest market share right now...

Maybe a profile would be useful :)

Are you sure this applies with the very latest Nvidia drivers?

Yep - having the latest GeForce2 Go driver. It's also no problem with MSIE, Opera, etc.

I've attached part of the Quantify data. BitBlt is called a lot by nsImageWin::BuildTile and nsRenderingContextWin::CopyOffScreenBits, but the majority of time is spent being by calls from nsImageWin::ProgressiveDoubleBlit. StretchDiBits is primarily called by nsImageWin::Draw and is where most of it's time is spent, but also is called by nsImageWin::ProgressiveDoubleBlit.

David, what was your latest tree pull when did you made this Quantify Data? I checked in a rewrite of ProgressiveDoubleBlit about 9 hours ago. Also, What OS are you using, and is that a nVidia card you have?

Also, this is really a dup of Bug 182544 or one of the many other slow animated bugs. Bug 182544 even has the same URL..

My build was from sometime last week, so I know it didn't contain your patch. I'll pull a new tree and try again and report back.

I don't think this URL is as valid as one that a single animated GIF... too many other potential issues. Changing URL.

With the new URL I don't see the CPU issue anymore. Looking at the paint function I see an overall 2.5 millisecond decrease with the patch or about 35% decrease in the paint function. While that sounds good I still see 100% CPU utilization with the patch. I'm not a big fan of using CPU usage to measure performance, though. IE could be blocking after each redraw, and give the appearance of lower CPU usage, while actually being slower. I think you'd need to compare the speed of the animation. How many frames can IE produce in the same amount of time as compared to Mozilla. Just looking at the CPU meter isn't going to give you a solid measure of what's going on. Seriously, I could put in some sleeps of a millisecond or so in paint, and while the visual speed might not change, the CPU usage could be greatly affected. For instance the patch below makes a marked difference in CPU usage for me without noticeably affecting the animation speed. Yet, I doubt we'd really want to do this: Index: nsImageWin.cpp =================================================================== RCS file: /cvsroot/mozilla/gfx/src/windows/nsImageWin.cpp,v retrieving revision 3.118 diff -u -r3.118 nsImageWin.cpp --- nsImageWin.cpp 24 Feb 2003 09:11:45 -0000 3.118 +++ nsImageWin.cpp 24 Feb 2003 21:48:18 -0000 @@ -1293,6 +1293,7 @@ aSrcDC, aSrcX, aSrcY, SRCCOPY); } } + Sleep(1); }

CPU usage expressed as a percentage (or whatever) is not going to be very useful to determine if this bug exists, or has been fixed. For example, my WinXP box runs at 100% CPU usage all the time. But this is because I'm running a low priority process that uses whatever spare CPU is available. Thus, I could say that IE shows the same problem as Mozilla.....as I'm at 100% anyway.

dbradley: what kind of graphics card and OS are you testing with? It is quite possible that the new URL doesn't peg anymore; I can't check because I don't have an NVidia card anymore; somebody just pick one from bug 86319 that does reproducibly peg. The multiple animated GIF issue is still separate from the NVidia issue, I think. Also, regarding CPU usage: both IE and Mozilla have a minimum limit for animated GIF frame refresh, and the display speeds are the same. Therefore something must be wrong with the way Mozilla is handling the updates (for example, if it is calculating displays at a rate faster than the minimum display refresh). Additionally, nothing about animation speed explains bug 87808, which I saw with an NVidia, but not really with an ATI gfx card. dgk: that's not a very strong argument because Mozilla isn't running on low priority. Besides, we're looking at what the application is using, not what the entire processor is doing. Anyway, as already stated, other browsers do not have this behavior, and when the CPU pegs, it tends to happen no matter what the speed of the computer.

I noticed that the initial load of an animated GIF uses lots of CPU (but not 100%), but once in cache the CPU load drops right down. nVidia GeForce2 driver v41.09 on WinXP.

OS is WinXP, the Video card is a GeForce4 440 Go (Dell Mobile) Driver is dataed 3/11/2002, version 2.8.3.5 >Anyway, as already stated, other browsers do not >have this behavior, and when the CPU pegs, it tends >to happen no matter what the speed of the computer. But I can reduce Mozilla's CPU usage by putting in the Sleep(1) statement and it doesn't noticeably slow the animation. By your measurement, that means it improves Mozilla. What we need is better data. How many frames is IE displaying per second/minute, and how many does Mozilla render.

While I agree that we need more quantitative data, the fact is that Mozilla's CPU pegging commonly makes the machine nearly unresponsive (though I haven't seen this lately). IE doesn't do that. Adding a sleep in there should also remove the unresponsiveness. Either way, IE /updates/ the image just as fast as Mozilla /updates/ the image in an animation (see bug 125137). However, I do not know anything about the way painting works. That's why I opened this bug for investigation. The point is that Mozilla uses a lot more CPU to do something with the same visual results as IE. This occurs predominately when using an NVidia graphics card and not so much with ATI (and maybe Matrox) cards. This is true for both graphics and DHTML when background images are used. The latter has a visually perceivable slowdown.

Don't get me wrong, I'm not arguing that there isn't a problem. I just want to make sure we understand the problem and spend our energy actually working on the "right" fix rather than potentially looking down the wrong paths. IE could very well have some kind of sleep in such animation sequence to free up the CPU for other tasks. Or it might execute the animation on a lower priority thread. Ideally any loop is going to utilizing 100% of the CPU as long as it doesn't block for I/O, or wait on other resources. Generally what causes loss of responsiveness in a system is kernal transitions and page faults. For instance, the 3D screen savers were notrious for this. They ran in a background thread, and took up relatively little CPU cycles. Yet they bogged things down because of the kernel transitioned encurred from doing intensive UI work. The point is, the problem and or solution may be much more complex and require looking at more things than CPU usage. Just adding the Sleep(1) fixes the CPU usage issue. Honestly in such an animation loop it might very well be part of the solution.

I think our biggest issue is page faults. With the kontek URL I don't see the page faults. With the original resource:///res/samples/test10.html I see page faults go through the roof for the Mozilla process. And few if any are transition faults. It seems to be related to kernel transitions. Privelege time jumps to about 30% with the test10.html, while it remains near zero with the kontek URL. So that would explain why systems are less responsive.

Oh, the difference between the two appear to be the use of "opacity" in test10.html. I don't see a problem when this isn't specified.

Then it's a dupe of bug 193849 ???

How about we just don't worry about opacity performance until I've fixed opacity to actually work properly? opacity isn't part of any standard yet and it's not much used on the Web yet either.

Since enter.gif doesn't seem to cause problems anymore, here's one that actually has issues even on my ATI card. I'll do more testing as soon as I get access to an NVidia machine again.

Ouch! This new URL is really hot... took 100% of 1.8 Ghz CPU (GeForce4). And we're back with an old bug... Changing hardware accelerate from full to full-1 reduces CPU to 20%-18%

FWIW the latest URL only utilizes 20% of my CPU regardless of hardware acceleration setting. One other variable is that I'm running dual monitors.

Interesting... it uses about 88% of one of my CPUs with my Radeon 9700 Pro...

Aaron: and now try to do this: 1) right-click on the desktop 2) choose properties 3) settings 4) advanced 5) troubleshoot 6) take 'hardware acceleration' one step down. 7) Accept changes 8) Check this URL once more. This is bug 170272 and i'm pretty sure it's not VIFEXD. I'm experiencing it on this bug.

Okay, that reduces it to 12%. Which means perhaps this image isn't a good testcase for the problem I reported, either. Again, I'll have to wait until I can test on an NVidia machine again. Can somebody with access to both type of cards test all the images in bug 86319 until they find one that matches the reported problems without the other problems? If not, just wait until next week.

Should behaviour from Comment 25 start new bug?

Yes.

Actually, I see 0% CPU usage with a build from today. Maybe Arron's checkin fixed that.

Yes, confirming. With todays build full accel = 14%, full-1 accel = 20%. So fortunatly there wont be new bug.

Since the animated GIF issue seems to be fixed, I'm replacing the URL with the one from bug 87808, though it could be considered a dupe now. I'd like to note that I do have problems on this URL with a P4 1.4/256MB RDRAM/WinXP/Matrox G450, so it might not be an NVidia-only issue. I haven't gotten a chance to test with NVidia yet. Also, set your resolution to 1280 or 1600 if possible otherwise the problem isn't so noticeable.

Did you try as mentioned in comment #21 with the hardware acceleration option too ?

How about this one? I don't see a problem with my Radeon, but WD does with his GeForce. http://bugzilla.mozilla.org/attachment.cgi?id=118586&action=view

Isn't this bug depending on any other one(s)?

*** Bug 151218 has been marked as a duplicate of this bug. ***

How are we doing with a recent build here?

This is still a problem with the latest nightly builds of firefox 1.6a and the latest nvidia drivers. The animation from comment #32 is very laggy when moving around the window while it's smooth on a much slower computer with a radeon. Reducing hardware acceleration in the display properties improves performance a lot.

The URL has animated image with transparent background. NVidia cards cannot handle it. See comment #9 in a bug 293222. NVidia may have fixed their drivers.

Upgrading to the now released nivia 8x drivers does indeed fix the problem! So this bug could proably be closed now. But it should be mentioned in the release notes.

1.5 years later does this still warrant a relnote? many nvidia issues were cleared up with their newer drivers in 2005

I think this could be now safely closed!