extreme slowness in dragging a layers on mousemove

RESOLVED WORKSFORME

Status

()

Core
Event Handling
--
major
RESOLVED WORKSFORME
17 years ago
13 years ago

People

(Reporter: Martin Jespersen, Assigned: Arun Ranganathan)

Tracking

(Blocks: 1 bug, {embed, perf})

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

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

17 years ago
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.
*** Bug 70328 has been marked as a duplicate of this bug. ***
Tom, I think this is very closely related to (if not even a dup of) bug 64516.
Quantify agrees with my thoughts too.

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

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

17 years ago
Gerardo, would you have this tested in other browsers to see if we are uniquely 
slow?  Did new imagelib help?  
Keywords: perf
(Reporter)

Comment 6

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

Updated

17 years ago
Keywords: nsbeta1

Comment 7

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

17 years ago
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?
The URL is no longer valid. Reporter, please attach a testcase.
(Reporter)

Comment 10

17 years ago
changed url to http://mbj.dk
Arun, please investigate and then find a correct owner (could be joki, but check...)
Assignee: joki → aruner

Comment 12

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 13

17 years ago
postings from n.p.m.performance...


Paul van Dam <paul.vandam@back2front.nl> 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 <Jiri.Znamenacek@idoox.com> 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

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

Comment 15

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

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

Updated

16 years ago
Blocks: 104166

Updated

16 years ago
QA Contact: madhur → rakeshmishra

Comment 17

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

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

15 years ago
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?
Blocks: 21762
Keywords: embed

Updated

15 years ago
Depends on: 163528
http://webfx.nu/dhtml/genresize/genresize.html is fixed by the patch in bug 163528
http://www.payplus.at also works fine now that bug 163528 has been fixed.

Comment 22

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

Updated

15 years ago
QA Contact: rakeshmishra → trix
Works for me also.
Marking as WFM due to no responce from reporter.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Updated

13 years ago
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.