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)
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.
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?
Gerardo, would you have this tested in other browsers to see if we are uniquely slow? Did new imagelib help?
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...
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
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.
Arun, please investigate and then find a correct owner (could be joki, but check...)
QA contact updated
postings from n.p.m.performance... Paul van Dam <email@example.com> 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.
The same problem is seen at the scrollbar at http://www.payplus.at
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.
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.
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.
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.
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?
All the working URL:s in this bug WFM, build 2002092908.
Works for me also. Marking as WFM due to no responce from reporter.