Hi again! Stefan and me are really hoping for a lot of feedback to this thread, since it's very important to us. Brendan, Jörn, John, Gilles, all the others, I would be glad to hear an opinion!
2006/11/27, Felix Geisendörfer <[EMAIL PROTECTED]>:
Hi Paul, thanks for this update. Yeah your example #1 (the current interface approach) demonstrates the problem of elements taking a long time to pick up very well. #2's drag lag is pretty bad too, but it still seems better then waiting 9 seconds (that's long how it took me on my dev machine) to pick up an element in example #1. Option #3 sounds pretty good, but as I don't use Yahoo / Live Mail I can't try it out in order to get a feel very easily. So depending on how it works, I would probably like to see all 3 versions implemented. Making the function smart in terms of selecting the appropriate type itself if no user setting has been made sounds like a great idea too. Other then that I would love to play around with experimental releases / svn HEAD or whatever would help you guys progressing on this. I could really need this feature ; ). -- Felix -------------------------- http://www.thinkingphp.org http://www.fg-webdesign.de Paul Bakaus wrote: Hi jQuerians! I had a long conversation with Stefan today (the guy who started the wonderful Interface library, for those of you who are new) about the performance of drag and drop operations. There are different approaches for both scriptaculous and interface and real-life applications: 1.) Interface's approach: Interface measures all possible droppables when initiating the drag. Advantages: 1.) After drag initalizing, dragging is very fast, does not lag, 2.) option to highlight possible drag targets at start Disadvantages: 1.) It takes a very long time to "pick up" a draggable, when dealing with lots of droppables. (See the demo: http://labs.pb-projects.de/test/index.html ) 2.) Scriptaculous' approach: Scriptaculous does nothing on drag start, but triggers a function everytime you move the mouse ("mousemove" event), which than checks for the position and looks if there is a overlapping droppable (droppable position by parsing the dom tree). Advantage: The dragging starts immediately. Disadvantage: Dragging is very slow when dealing with lots of droppables (especially deep nested ones). (See the demo: http://labs.pb-projects.de/test/index2.html) 3.) Real world approach (Yahoo, Live Mail, others) Instead of using the real draggable element, the use a helper div, which is attached to the cursor. Notice: The cursor is not _over_ the helper, but has an offset of i.e. -5/-5 relative to the helper. Advantage: Very very fast in performance, because you can check for the target/srcElement, rather than checking the position of droppables Disadvantage: The cursor cannot be on top of the helper. We now came to the conclusion that we should have 2 or 3 versions of Draggables: 1.) The old one (Nifty but slow, for few droppables) 2.) The new one (Fast, event delegation [without parsing the DOM tree], but needs some tweaking parameters every time) 3.) The helper draggables (very fast, cursor must be off the element) For making it easier to decide which to use, we could provide a helper on top, draggables.js, that automatically selects the preffered version in regards of how many nodes you use for droppables and where the cursor position is. We are waiting for comments and ideas on this very important decision, since it will be a major rewrite and change. -Paul -- Paul Bakaus Web Developer ------------------------------ _______________________________________________ jQuery mailing list [EMAIL PROTECTED]://jquery.com/discuss/ _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
-- Paul Bakaus Web Developer ------------------------ Hildastr. 35 79102 Freiburg
_______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
