69354 - extreme slowness in dragging a layers on mousemove

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Martin Jespersen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010215
BuildID:    2001021508

Try dragging the logo in the top left corner versus dragging the mainlayer (both
are draggable). The logo is no problem but the larger layer (which is actually 4
or 5 layers being dragged around together) has big problems... actually it won't
move the layers until the mouse stops moving at all most of the time.

Reproducible: Always
Steps to Reproduce:
look in the description... just drag 'em and see

Actual Results:  slow dragging of large layer/no drag until mouse stopped moving

Expected Results:  realtime dragging of selected layers

it only seem to be onmousemove that creeates this problem since moving many
layers at once on e.x. mouseclicking seems to be instant and flawless (which by
the way was a huge improvement from version 0.7)

Comment 1

[Greg Breland]

My Bug:70328 seems to be one and the same problem.  My case is simple, but
adding more complex layout inside the layer that is being moved increases the
lagg until you get to a point that the layer can not be re-drawn until you quit
moving because 100% of the CPU is being used to reflow the content.

Comment 2

[Johnny Stenback (:jst)]

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

Comment 3

[Johnny Stenback (:jst)]

Tom, I think this is very closely related to (if not even a dup of) bug 64516.
Quantify agrees with my thoughts too.

Comment 4

[Greg Breland]

I agree that bug 64516 and this are basically the same problem except for we 
this bug uses the mouse to move the layer around as opposed to a js timer 
event.  If you get the speed of moving layers faster, the mouse movement will 
in turn probably fix itself.  How about marking bug 64516 as a blocker to this 
bug?

Comment 5

[clayton]

Gerardo, would you have this tested in other browsers to see if we are uniquely 
slow?  Did new imagelib help?  

Comment 6

[Martin Jespersen]

i have allready tested it from netscape 4.0 and up and ie 4.0 and up on both mac 
and windows... mozilla is uniquely slow, although the only browser to handly it 
perfectly is ie on windows...

Comment 7

[Gilles Doyen]

Sorry about the pressure, guys, but for us, fixing this bug is quite vital.
Current performance and appearance is awful and we really need this to work as
designed. Thanks for your dedication and help, it is appreciated! GD

Comment 8

[clayton]

We want to check if the new imagelib landing has helped.
Arun, would you see if a content workaround is already being used in the field?
 Would you look at the code and CSS style sheets for known performance issues?

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The URL is no longer valid. Reporter, please attach a testcase.

Comment 10

[Martin Jespersen]

changed url to http://mbj.dk

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Arun, please investigate and then find a correct owner (could be joki, but check...)

Comment 12

[Madhur Bhatia]

QA contact updated

Comment 13

[Cathleen]

postings from n.p.m.performance...


Paul van Dam <[e-mail]> wrote:
> 
> Check the example:
> 
> http://www.xs4all.nl/~pcvandam/dynobj2/do2test.html
> 
> While IE and even NS4 does this easily, Mozilla (even 0.9.2) barely gets the
> thing moving. It takes 100% processor power on a P3-800 dragging the window.
> 
> Mozilla has some terrible DHTML performance...
> 
> Paul van Dam
> 
> 

Jiri Znamenacek <[e-mail]> wrote:
> the fantastic ieemu.js library and is as quick as IE is. On the other hand 
> http://webfx.nu/dhtml/genresize/genresize.html provides resize through the 
> same library and in Mozilla is slow as a hell.
> I also remember someone's "paint" JS program, which created DIVs with 
> background color, and it was also slow as a hell in Mozilla.
> 
> 
>  Jirka
>
>  PS: On the other hand - have you ever tried to detect quick clicks on the 
>  page? IE is completely helpless in this task.

Comment 14

[Markus Hübner]

The same problem is seen at the scrollbar at
http://www.payplus.at

Comment 15

[Matt Perkins]

I found a dirty work around that speeds it up for me. I put a form field on the
page and in my onmousemove function, it updates the field with a counter
variable. This seems to force the page to update more frequently. Dragging is
still MUCH slower than with IE (using Windows). Without this counter going, I
get 100% CPU, with it I get 98%. With IE, I get between 30-50%. I have an
example up at: http://www.kheavy.com/temp/dragtest/test.html
You can toggle my fix on (default) and off.
The field can be placed in a DIV and hidden off screen.

Comment 16

[Robert Rainwater]

Here's another example:
http://jsdomapi.sourceforge.net/jsdom/docs/docs/examples/jsdom.components.window.html

In IE the dragging is smooth, but in Mozilla the refresh rate is horrible.

Comment 17

[Markus Hübner]

Testing http://www.kheavy.com/temp/dragtest/test.html with build 2002041903 on 
win-xp,1.1ghz,512RAM seems to be smooth. 
Reporter: please verify with a current build.

Comment 18

[Matt Perkins]

Comfirmed. On my AMD 1.1, 512mb and winXP, that build is much faster! There 
are some display issues when the DIV's are dragged over each other with out 
the "moz fix", but a big improvement. I think that problem is with the 
mozopacity property.

Comment 19

[Markus Hübner]

from a posting to n.p.m.performance:
---
I found that dragging a layer in mozilla is very slow and checked in bugzilla 
if thats a known issue. It is, you can find it as Bug 69354. The issue is 
rather old, but it seems like there is no solution yet.

We tested it in Mozilla 1.0 on Linux and in Netscape 7 on Windows XP. The 
windows machine is a P4 1.8 GHz, the linux box is a P3 800 MHz. Naturally the 
P4 performs a bit better but it still sucks.

I wondered what priority this one has or if someone is working on it or has 
conducted some thorough performance/debugging tests. From the issue in 
bugzilla I conclude that it is not so sure where the problem is located...
---

What's the current status/plan on this one?

Comment 20

[Kevin McCluskey (gone)]

http://webfx.nu/dhtml/genresize/genresize.html is fixed by the patch in bug 163528

Comment 21

[Kevin McCluskey (gone)]

http://www.payplus.at also works fine now that bug 163528 has been fixed.

Comment 22

[José Jeria]

All the working URL:s in this bug WFM, build 2002092908.

Comment 23

[Zibi Braniecki [:zbraniecki][:gandalf]]

Works for me also.
Marking as WFM due to no responce from reporter.