295980 - Transparent and animated GIF -- poor rendering performance on nVidia video cards

Status: VERIFIED WORKSFORME

(Core Graveyard :: GFX: Win32, defect)

Description

[Igor Levicki]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Using Firefox 1.0.4 I have noticed that with certain pages it has rather poor
rendering performance. What is even worse, effects are detrimental to the whole
system and bring even the fastest computers to their knees.

Examples of such pages would be:
1. http://www.homepages.hetnet.nl/~brianpostma/pc.html
2. http://www.world-direct.at/mozilla/dhtml/75121/anim-test.htm
3. http://www.pcstats.com/i/pcs_IEbkgrnd.gif

First page has two sources of slowdown. One of them is java applet which can be
turned off and the other is the transparent GIF used as a body background image.
Second page is a GIF animation having up to six times slower performance than in
competitive products IE and Opera.
Third page is also transparent GIF image that causes the same slowdown when
scrolling.

I have searched bugzilla and found several bugs that seem to have something to
do with this. Reason why I have opened a new bug for this is because after some
research I believe that it has to do with video card and drivers. I have
contacted Mike Connor who said that I should file my findings under core: gfx
win32 and cc him so he can check with nVidia about this. There is a chance that
this issue (or part of it) has already been fixed in a nighty trunk but there is
a risk that it will be reintroduced if it doesn't get enough attention.

This has been tested on two configurations -- one using Intel 630 and one using
AMD64 3000+ CPU and both of them equipped with 1GB RAM and nVidia 6600GT video
card running under Windows XP SP1 with 71.89 WHQL'd drivers. While both
computers take heavy performance hit on mentioned test pages profiling was done
only on Intel 630 using latest version of VTune.

Methodology of profiling was to launch quick performance analysis project using
firefox.exe and passing the URLs #2 and #3. Since VTune collects the samples for
20 seconds there was plenty of time for the page/image to load and render on
ADSL 256kbps connection. I used scroll wheel to scroll the page or image up/down
for the duration of the sampling (20s). Then the same process has been repeated
with hardware acceleration reduced by one notch in display properties and here
are the results:

According to the VTune 99% of the time is spent in win32k.sys in
EngStretchBltROP() function when hardware acceleration is set at full.

However, with reduced hardware acceleration as I suspected distribution of time
spent in various modules and functions is completely different -- win32k.sys is
accounted for only 11% of the time and that dreaded EngStretchBltROP() is
nowhere to be seen. Instead of it the function that takes most of the time in
win32k.sys is vSrcCopyS24D32(). nv4_disp.dll and nv4_mini.sys which were not
even listed when acceleration is set to full take only 2.5% and 0.4% of the time
respectively.

Quick search on Google for EngStretchBltROP() led me to this page:
http://www.osronline.com/ddkx/graphics/gdifncs_4jzb.htm

It says in the comment at the bottom of the page:
"The driver should call EngStretchBltROP if it has hooked
DrvStretchBltROP but cannot support all operations."

This leads me to believe that this "bug" has something to do with broken video
drivers. What I suspect is that driver somehow _turns on_ hardware acceleration
when you reduce it in display properties and vice versa.

Perhaps IE and Opera have some workaround for this since they are not affected,
or they just use different raster operations for rendering?

If I can be of any more help regarding this, drop me an email.


Reproducible: Always

Steps to Reproduce:
1. Visit the pages or open the images I suggested and after the page or image
has finished loading try scrolling up/down.
Actual Results:  
Scrolling is slow, performance of the entire computer is affected. CPU usage
goes up to 100% on AMD and up to 50% on Intel due to HyperThreading.

Expected Results:  
Scrolling should be fast and smooth.

Comment 1

[Igor Levicki]

I have also posted this info on forums.nvidia.com:
http://forums.nvidia.com/index.php?showtopic=5105

Comment 2

[Steve England [:stevee]]

Scrolling is fast and responsive for me.
Win2ksp4, nVidia GeForce4 Ti4400, 1280x1024x32 @ 85Hz, hardware acceleration full.

With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050509
Firefox/1.0.4 test 2 takes ~4300ms

With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050530
Firefox/1.0+ ID:2005053004 test 2 takes ~ 1500ms.

Reporter, please test the latest nightly firefox 1.1alpha builds to see if this
problem has already been fixed. You can get the Developer Preview RCs from
- http://weblogs.mozillazine.org/asa/archives/008227.html
I advise you use a new profile when running.

Comment 3

[Igor Levicki]

(In reply to comment #2)
> Scrolling is fast and responsive for me.
> Win2ksp4, nVidia GeForce4 Ti4400, 1280x1024x32 @ 85Hz, hardware acceleration full.

You haven't listed your CPU speed and video driver version. I have seen in
forums that some people have less slowdown than you and me for 1.0.4 with 66.93
drivers.

> With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050530
> Firefox/1.0+ ID:2005053004 test 2 takes ~ 1500ms.

That is the approximate time IE and Opera give to me.

> Reporter, please test the latest nightly firefox 1.1alpha builds to see
> if this problem has already been fixed. You can get the Developer Preview
> RCs from
> - http://weblogs.mozillazine.org/asa/archives/008227.html
> I advise you use a new profile when running.

I have downloaded and tested Deer Park 1:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050527
Firefox/1.0+

It seems that the issue has been fixed in the trunk build. No more high CPU
usage when scrolling and animation runs fast as it should. I really hope it is
fixed for good and that it won't regress again when M$ updates their OS or
nVidia their video drivers. Could someone tell how long we should wait until 1.0.5?

Comment 4

[Steve England [:stevee]]

My CPU is AXP2400 and my nVidia drivers are v76.41
IF firefox 1.05 is released, this issue will not be fixed in it; only security
issues are going to be fixed on the 1.0x branch. All the hard work (over 1800
bug patches and counting) is being done on the trunk in preparation for Firefox
1.1, which will be out in 2-3 months I'd guess.
Resolving WORKSFORME.

Comment 5

[Igor Levicki]

(In reply to comment #4)
> My CPU is AXP2400 and my nVidia drivers are v76.41
> IF firefox 1.05 is released, this issue will not be fixed in it; only security
> issues are going to be fixed on the 1.0x branch. All the hard work (over 1800
> bug patches and counting) is being done on the trunk in preparation for Firefox
> 1.1, which will be out in 2-3 months I'd guess.
> Resolving WORKSFORME.

Do you please have any suggestion which version should I use by then? Would it
be possible to reconsider slipping this fix in to 1.0.5?

Comment 6

[Mike Connor [:mconnor]]

No, the 1.0.x branch is stable in the sense of being consistent, security fixes
and major regressions from post-1.0 fixes only, unless there's a huge case to be
made here.

Comment 7

[Steve England [:stevee]]

Plus does anyone have an idea of what patch from the 1800+ that have landed for
1.1 has actually fixed this issue? I don't, though my first *guess* would be bug
284716.

Comment 8

[Igor Levicki]

(In reply to comment #6)
> No, the 1.0.x branch is stable in the sense of being consistent,
> security fixes and major regressions from post-1.0 fixes only,
> unless there's a huge case to be made here.

I personally believe that there is a huge case here. Here is why -- if there is
50 mil. people using Firefox, than at least 50% of them is using nVidia based
video card. That means 25 mil. people has poor browsing performance whenever
they hit a web page with animated GIF or transparent GIF background which can be
pretty often. They get annoyed by poor performance not expected from such a
lightweight browser and they get back to using IE or Opera because Firefox
doesn't cover all of their browsing needs. I am not trying to convince anyone
here, this is just the way I see it from an end-user perspective.

(In reply to comment #7)
> Plus does anyone have an idea of what patch from the 1800+ that have
> landed for 1.1 has actually fixed this issue? I don't, though my first
> *guess* would be bug 284716.

Well, to be honest, I do not like the idea of "fixing" this issue this way
without checking what exactly is going on inside of GDI and nVidia drivers. If
this is nVidia or Microsoft bug then it is not Mozilla team who should change
their code to work around it, because if it gets really fixed by Microsoft or
nVidia there would be a risk of regression.

Comment 9

[Mike Connor [:mconnor]]

asserting that of 50 million users half are using an nvidia card ignores basic
market share data, i.e.
http://www.jonpeddie.com/about/press/MarketWatch_Q105.shtml which puts nvidia
around 17%, not 50%.

That aside, if major arch changes in gfx/win32 (possible) were made, we're not
putting those on a stable branch.  1.1 should drop this summer, and affected
users can upgrade, or turn down HW acceleration.  If there was a safe and
unintrusive patch, great, but there's not a strong enough argument to put scarce
resources into a branch fix for something with a workaround.

Comment 10

[Igor Levicki]

(In reply to comment #9)
> asserting that of 50 million users half are using an nvidia card ignores basic
> market share data, i.e.
> http://www.jonpeddie.com/about/press/MarketWatch_Q105.shtml which puts nvidia
> around 17%, not 50%.

Mike, have you read that page carefully? It says:

"ATI maintained its lead in the discrete desktop segment during Q1'05 by a
margin similar to that of the fourth quarter. ATI's discrete desktop shipments
declined 9.0% sequentially and its share in the segment fell slightly from 51.9%
in Q4'04 to 51.4% in Q1'05. Nvidia's discrete desktop shipments declined 8.0%
sequentially and its segment share was essentially flat, growing from 46.7% to
46.8% during the same period."

When I was talking about roughly 50% percent I meant desktop segment and not the
entire market and I was close enough (46.8%). While I cannot discuss what amount
out of 50 mil. downloads of Firefox are desktop users it is pretty safe to say
it is majority of them, right? So perhaps my presumption was not that far away
from the facts. Not to mention it is a core "feature", and that means not only
Firefox is affected so there may be even a larger base of annoyed users.

> That aside, if major arch changes in gfx/win32 (possible) were made, we're not
> putting those on a stable branch.  1.1 should drop this summer, and affected
> users can upgrade, or turn down HW acceleration.  If there was a safe and
> unintrusive patch, great, but there's not a strong enough argument to put scarce
> resources into a branch fix for something with a workaround.

Unfortunately the workaround is not simple enough. Simple workaround would be to
once perform one operation to enable normal use of browser. Turning down
hardware acceleration before browsing and back up after it to be able to play a
game or watch the video and having to do it each time you want to do one or
another is equally acceptable as having to run unstable build which is not
compatible with the majority of those much needed extensions.

What I am suggesting is to work closely with nVidia to determine if this is
their (or Microsoft) bug and only then acting upon it.

Comment 11

[Mike Connor [:mconnor]]

Discrete translates to "add-in cards" i.e. not onboard, which is what all of
Intel's solutions do.  Anyway, not going to debate the market share issue now,
its irrelevant, since there's no way we're going to go fishing for a fix that
may or may not be too risky to take on the branch.  We don't have limitless
resources, and this would be a bad use of those resources as we're trying to
ship the next full release in a timely fashion.