#5562 closed defect (fixed)
Dialog: slow/jumpy dragging (IE)
Reported by: | guest | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit | Version: | 1.0 |
Keywords: | dijit dialog dnd | Cc: | Douglas Hays |
Blocked By: | Blocking: |
Description
I notice that the Dialog moves in IE is not smooth like in firefox, but the FloatingPane? widget can draged very smooth in both IE and Firefox. Also the 0.4.3 dialog does not have this situation.
I compared the underlay domnode generated by 1.0.2 and by 0.4.3. There is a bit difference. I think it can be fixed easily.
Thanks.
Attachments (3)
Change History (13)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
I just found that there are 2 divs in the new underlay template, and the iframe created by 1.0 is placed in the underlay dom node but the 0.4.3's placed under the html body tag.
I am not sure that is the reason caused the slowdown, just guess.
comment:3 Changed 13 years ago by
Milestone: | → 1.2 |
---|
Changed 13 years ago by
Attachment: | 5562_onMoveTimer.patch added |
---|
add timer to Moveable to reduce calls to dojo.marginBox to help IE performance
comment:6 Changed 13 years ago by
Milestone: | 1.2 → 1.1 |
---|---|
Owner: | set to Douglas Hays |
Seems to be linked to the use of expression() in dijit.css.
comment:7 Changed 13 years ago by
comment:8 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [12806]) Fixes #5562, #6024. Re-evaluation of IE's CSS expressions was causing a slow down. Occasionally the expressions would throw an error causing the "Invalid argument". Removed IE font-style and font-weight inheritance from input tags used in dijit widgets to prevent css expression re-evaluation. Font-family and font-size are still inherited by child input nodes as before, but if the parent node's font-family changes (unlikely), the child input node will not pick up the change. This prevents constant css expression re-evaluation. All font attributes can still be specified for the input node if the IE defaults are not acceptable.
comment:9 Changed 13 years ago by
Summary: | dijit.DialogUnderlay make the dialog dnd move slow in IE → Dialog: slow/jumpy dragging (IE) |
---|
Note from Doug: the floating pane tests probably dragged smoother because they didn't have TextBox widgets, which means that IE wasn't reevaluating an expr() every time the FloatingPane changed position.
Changed 13 years ago by
Attachment: | Moveable.js added |
---|
test file to compare performance of various approaches
Changed 13 years ago by
Attachment: | performanceTest.patch added |
---|
test file to compare performance of various approaches
comment:10 Changed 13 years ago by
I attached the changes I made to test performance in Moveable.js (goes in dojo/dnd/) and the performanceTest.patch file (apply against [12931]). Also temporarily stored in test_Dialog.html in my home directory.
I found that on a real windows machine (but curiously not parallels), running IE6 (not IE7), you can definitely see the problems if you try continuously dragging the dialog in circles (without ever stopping movement). Actually you can see a difference also in test_moveable.html with the timer code vs test_moveable w/out the timer code but not as severe.
Here are my findings, although anyone curious should just try the page/patch themselves:
- dragging is sluggish on IE6. Actually the dialog doesn't redraw until you stop moving the mouse.
- The expressions aren't making any difference since they are only evaluated at load time.
- the timer is making a big improvement
- part of the problem is the repeated dojo.marginBox() calls in Moveable.js. With that changed to a plain
node.style.top = ...
expression, the dialog draws significantly better (even without the timer)
- removing the underlay also makes performance a lot better.
Conclusions: I think Moveable.js should be changed to not keep calling dojo.marginBox() to set the left/top on the drag object. (There probably isn't a margin anyway, and if there is it doesn't affect position:absolute nodes, and in any case the margin doesn't change as you are dragging). That should help Dialog in addition to making dragging of other objects on IE smoother. In addition there is something weird going on with that underlay that should be looked at.
Having fixed those two problems I suspect we don't need a timer.
So you found a difference between the 0.4 underlay and the 1.0 underlay that causes a slowdown? What did you find exactly?