Closed Bug 197341 Opened 21 years ago Closed 18 years ago

[win32 event issue] Mouse movement during animation run improves DHTML performance

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: manfredps, Unassigned)

References

(
URL
)

Details

(Keywords: perf, qawanted, testcase)

Attachments

(1 file)

Testcase
1.17 KB, text/html
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461; COM+ 1.0.2204)
Build Identifier: 1.3

If moving the mouse around in the window, you will notice that the DHTML 
animation runs siginificantly faster.
On my slow 400 MHz machine at home, I have experienced differences of more than 
100%. The differences
are up to 15% on my 1900 MHz machine at the office.

Further, I have experienced a 'glass' effect - objects behind specific opaque 
objects move by 1 pixel on their y-axis.
This appears only if the following conditions come together:
- There is an object with an invalid -moz-opacity value or a value of 0
- There is another object with a valid -moz-opacity value
- The objects are moved at the same time by an unrounded numeric value (i.e. 
1.1 pixels)
It will appear to all opaque objects then.
When starting, you will see opaque 'stripes of glass' influencing this text 
block. Some rendering errors will stay. 

Tested on AMD K6-2/400 WinME and AMD Athlon XP 1900 Win2K, Mozilla 1.3 20030302 
and Phoenix 0.5 (Gecko 1.3a 20021207).
Both effects did not appear on Mozilla 1.2a 20020910 and Phoenix 0.1 (Gecko 
1.2b, 20020923). 

Reproducible: Always

Steps to Reproduce:




This appears on all 1.3 Gecko builds I've tested, including Phoenix 0.5, but 
not on 1.2. The performance difference seems not to be too big on a fast 
machine (1900 MHz), but is really significant on a slow machine. Slow machines 
(400 MHz) could render most DHTML animations smoothly if this bug would be 
removed. For now, it looks as if users with slow machines have to move their 
mouse to see smooth animations. :)
For me pressing the first link and then moving around the mouse gives me a 16%
slower (?!) result instead of no mouse movement.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, testcase
Blocks: 21762
José, could it be that you had the glass effect running while measuring? This 
puts at least on my office machine such a heavy load on the renderer that the 
mouse movement doesn't make a difference anymore and time measurement results 
vary independently of it. Besides, it would be interesting to know your Mozilla 
build, OS, machine etc.
Build 2003031308, Windows 2000, Pentium III 500 Mhz, Nvidia TNT 2 with latest
drivers (from nvidia.com). 

20% slower if I move the mouse around without the hour glass.


Dont see any performance with Athlon 1.8+ 256 DDR and Mozilla 2003031308
(Windows) GeForce 4
Tested on Moz 1.3 20030312 (same as mine), Win XP, P3 500MHz, and there was 
also a performance loss on mouse movement instead of performance improvement. 
The 'glass' effect, however, appears also on this system.
I do see a difference! Get a 16% performance boost when moving the mouse.
Using trunk build 2003031308 on winxp pro sp1, 1.1ghz, 512ram, 
GeForce2Go@32Bit with latest driver.

Over to kevin; sounds like more Win32 event crap.
Assignee: other → kmcclusk
Not seeing any performance difference under 1.3 on a dual celeron 466, Win2k,
Matrox G550. Perhaps yet another nvidia anomaly.

b.t.w reporter, you should only submit bugs for Mozilla, not IE 5.5 ;-)
Once more. No, it does not affect _all_ nvisdia drivers. I have GeForce4 with
newest signed drivers on Windows XP and really i dont see this effect.
Meaby it's GF2/GF3 only?
Ok. Forget my last comment. I just downloaded todays build and todays drivers to
GF. I see up to 20% speed burst now when moving pointer over divs.
Mozilla 1.2 (20021126), w2k, PIII 900, Kyro II graphics card. 15% improvement 
when mousing like hell. So it's not 1.3 only...
What chipset is used in Kyro II ?

On Linux so far there is a slowdown - of about 10% - when moving the mouse.

updating summary based on comment #11
Summary: Mouse movement during animation run improves DHTML performance and opacity influences objects behind - both only in 1.3 → Mouse movement during animation run improves DHTML performance and opacity influences objects behind
tried this on a virtual WinNT machine:

Dual P3/450/256MB
OS: RedHat 6.2
VMWare
WinNT - VM has 128MB allocated

Extensive mouse movement makes test upto 30% slower!!!
Probably Linux behaviour is a material for another bug, isn't it?
Um.  On _Linux_ you move the mouse, that hoses the X server, drawing operations
get a lot slower.  Because mouse stuff is expensive in X.  Nothing to move
there, move along.
Hmm.. additional info. I dont have to move pointer over divs! It's enought if
i'd move mouse pointer over screen anywhere...
11% slower when moving the mouse 2003030708 trunk release Mozilla build.
750Mhz AMD running WinXP.

Moving the mouse triggers flushing of the pending reflow events, so I would
expect it to be slower. Not sure why others are getting a faster time.

> What chipset is used in Kyro II ?

Um, Kyro II? ;-) The actual graphics card is a Hercules 3D Prophet 4500. The 
chipset is called "Kyro II" and comes from Imagination Technologies, 
http://www.powervr.com/ . I.e. not nVidia -- thought that would be of (some) 
interest that it obviously isn't related to that manufacturer.
Tests on the workstations in our office showed that some have the behaviour 
and some not - hm.
I see this on win2k as well as on winxp, on several graphic cards and several 
cpu chips.

Any ideas what could be causing this resp. an approach how to fix that?

With a P4 2,53 ghz and a ATI Radeon 9500Pro on Windows 2000 I see the following:
First run without moving the mouse: 3796 ms
Second run with moving the mouse: 3282 ms
Third run (only for verifing) (also moving the mouse): 3235 ms

Thats about 14-16 % faster when moving the mouse.
another set of runs on that testcase - 2003031408 on win2k, Pentium 4 1700, ATI
Rage 128 Ultra (onboard mobo).

no mouse movement:
4031, 4062, 3984, 4000, 4078, 4109 (avg 4044)
with movement:
4000, 4016, 4031, 4015, 4015, 4000 (avg 4013)

faster, but by less than 1%...
As I have experienced the biggest speed boost on my slow 400MHz machine at home 
(having terribly slow animations becoming really smooth as the result of just 
some mouse movement), it probably would make sense to test it on more slow 
machines. Anyone?
20030312 (1.3 final), NT4, P200MMX, 96MB, Matrox Millennium II: 15% slower. But 
the /real/ slowness comes from alternating mousing over the browser navigation 
area and the actual page -- I could easily get 50-70% slower results, compared 
to the measly 15% when just mousing over the "canvas".
during the "mouse move speedup" does the CPU load go up or down?
When moving the mouse the cpu load goes up compared to the testrun when no 
mouse-movement is done (it doesn't reach 100% - just for info).


On Mac OS X, moving the mouse slowed it down by about 13%. So this is likely a
Win32 event issue.
AV: do you think this could be related to the event throttling code, bug 132759?
Well, I doubt it. But to make sure, one may want to comment out lines containing
|SubclassAndAssociateWindow| ans |UndoSubclassAndAssociateWindow| inside
|nsPluginNativeWindowWin::CallSetWindow| method body and try it without subclassing.
Can someone try this and upload the win32 build somewhere for testing?
Priority: -- → P2
Target Milestone: --- → Future
CC'ing for help
build with said change available from:
http://stud4.tuwien.ac.at/~e0225227/bin.zip

note, the used sources are from apr 6. it also includes a small unrelated change
to .ico images.
I still se performance on mouseover with build from Comment #34
Well, this is clearly a win32 event issue.
This needs someone knowing this stuff doing some investigating and tracking 
this down.
Summary: Mouse movement during animation run improves DHTML performance and opacity influences objects behind → [win32 event issue] Mouse movement during animation run improves DHTML performance
Blocks: 203448
I'm interested Linux flavor this bug. 
The testcase URL 
http://www.world-direct.com/mozilla-opacity-performance-testcase/
no longer valid. 
Can somebody please post a current re-create testcase URL please.
Thanks,
Sam
testcase URL is back again :)

Also with latest trunk build (2003072404) I do see the same as reported in
comment #6

A quick check showed that moving the mouse lowered the number of paint events by
about one third (something like 900 to 600). 
Using trunk build 2005060906 on winxp pro sp2 I still do see the same (11% 
performance improvement in the testcase when moving the mouse).
Assignee: kmcclusk → nobody
Keywords: qawanted
Attached file Testcase — 
Follow the steps in the testcase, my results:
Result 1: 8202 ms
Result 2: 6750 ms
Using Firefox trunk build on Win2000.
"test settimeout1" and "test settimeout2" are the same, the only difference is
that the user should move it's mouse with test2.
The timers seem to be too slow in general, but that's bug 257454.
Target Milestone: Future → ---
Depends on: 257454
This seems to be down to 1.5-3% difference with moving the mouse rapidly taking slightly more time. Bug 326273 likely improved this. Fixed?
With a linux trunk build from 20060512 (post threadmanager):

Not moving the mouse:
Result 1: 5027 ms
Result 2: 5017 ms

Moving the mouse (wildly):
Result 1: 5047 ms
Result 2: 5017 ms

> With a linux trunk build from 20060512 (post threadmanager):

Doh!  I meant Windows, not Linux.

With a FF 1.5 build, I get these results (not moving the mouse):
Result 1: 8181 ms
Result 2: 8422 ms

With IE 6, I get these results (not moving the mouse):
Result 1: 5027 ms
Result 2: 5017 ms

So, I'd say that this bug is definitely fixed.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Depends on: nsIThreadManager
Assignee: nobody → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: