Closed Bug 197341 Opened 23 years ago Closed 20 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: 20 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: