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

RESOLVED FIXED

Status

()

Core
Layout
P2
normal
RESOLVED FIXED
15 years ago
10 years ago

People

(Reporter: Manfred Schneiderbauer, Assigned: Nobody's working on this, feel free to take it)

Tracking

(Blocks: 1 bug, {perf, qawanted, testcase})

Trunk
x86
Windows 2000
perf, qawanted, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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. :)

Comment 1

15 years ago
For me pressing the first link and then moving around the mouse gives me a 16%
slower (?!) result instead of no mouse movement.

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, testcase

Updated

15 years ago
Blocks: 21762
(Reporter)

Comment 2

15 years ago
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.

Comment 3

15 years ago
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
(Reporter)

Comment 5

15 years ago
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.

Comment 6

15 years ago
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

Comment 8

15 years ago
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.

Comment 11

15 years ago
Mozilla 1.2 (20021126), w2k, PIII 900, Kyro II graphics card. 15% improvement 
when mousing like hell. So it's not 1.3 only...

Comment 12

15 years ago
What chipset is used in Kyro II ?

Comment 13

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

Comment 14

15 years ago
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

Comment 15

15 years ago
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...
See comment 7.
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.

Comment 21

15 years ago
> 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.

Comment 22

15 years ago
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.

Comment 24

15 years ago
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%...
(Reporter)

Comment 25

15 years ago
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?

Comment 26

15 years ago
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".

Comment 27

15 years ago
during the "mouse move speedup" does the CPU load go up or down?

Comment 28

15 years ago
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).

Comment 29

15 years ago
On Mac OS X, moving the mouse slowed it down by about 13%. So this is likely a
Win32 event issue.

Comment 30

15 years ago
AV: do you think this could be related to the event throttling code, bug 132759?

Comment 31

15 years ago
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.

Comment 32

15 years ago
Can someone try this and upload the win32 build somewhere for testing?

Updated

15 years ago
Priority: -- → P2
Target Milestone: --- → Future

Comment 33

15 years ago
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

Comment 36

15 years ago
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

Updated

15 years ago
Blocks: 203448

Comment 37

15 years ago
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

Comment 38

15 years ago
testcase URL is back again :)

Comment 39

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

Comment 40

15 years ago
A quick check showed that moving the mouse lowered the number of paint events by
about one third (something like 900 to 600). 

Comment 41

13 years ago
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
Created attachment 186593 [details]
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.

Updated

13 years ago
Target Milestone: Future → ---
Depends on: 257454

Comment 43

12 years ago
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?

Comment 44

12 years ago
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

Comment 45

12 years ago
> 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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Depends on: 326273
You need to log in before you can comment on or make changes to this bug.