But, I can say that IMHO, the entire drag/drop library could stand some major optimization-centric changes...
Also, here's a drag/drop riddle for you all. Try creating 2 floating dialog windows (use whatever dialog library you can find, there are many)... make the content div in each one a Droppable. Now move them in such a way that they overlap each other. Now move a draggable (from anywhere else on the page), and try to drop it into the topmost dialog, being sure you drop it in an area the is also covered by the bottom droppable. Which droppable actually gets the drop event? The answer is, whichever one was created first. Now, try to fix that problem using the current drag/drop library. You have 1 Draggable and 2 Droppables. Both droppables must be able to accept the Draggable, but only the one on top should actually accept it if the Draggable in dropped in an overlapping area. Now, if you solved that, tell us how... and try implementing your solution generically so it would work with 25 droppable dialogs, etc...
I'm not saying the above is impossible, but it's not straight forwardly easy, that's for sure. There are definite limitations to dragdrop.js.
On 6/16/06,
Kjell Bublitz <[EMAIL PROTECTED]> wrote:
I just found out that OnChange on a Sortable is firing constantly on each mouse move. This is mostly noticable if the currently dragged object is moved over its start position. I commented out everything related to it but still calling and calling.. I think i will see what i can strip out and hopefully dragging won't make my CPU go to 100% anymore in IE. .. There was a time when IE was faster then other browser since the close OS implementation .. now it actually seems to be the slowest one when it comes down to a bit more complex actions. strangly enough..
I am still not sure where the leak is. Either the rapid functions calls, the dragging/positioniong OR the collision detection. :(
RegardsOn 6/16/06, Ryan Gahl <[EMAIL PROTECTED]> wrote:Right, I'm not personally destroying the Draggable on mouseout, although there may some use cases out there to argue for that and it may aid in the area of improving overall drag preformance.
But... Tom's idea is good because it moves the point of instantiation even later in the process. I just hadn't gone that far as I wasn't sure if that could be implemented smoothly or not. But yes... ideally, waiting until mousedown would be best (lol, or maybe mousedown + mousemove).
But generally speaking, it's all about the idea of only applying functionality at the very point at which it's needed (or as close to it as possible), as long as that act of applying the functionality itself doesn't impede the application performance. It's all about balance.On 6/16/06, Gregory Hill < [EMAIL PROTECTED]> wrote:> If you're creating them on mouseover and destroying them on mouseout,
> why not wait until mousedown to create the draggable? You'd have to
> "prime the pump" as the mousedown event it's looking for has already
> occurred, but it does work. Looks something like this:
Well, I think Ryan (to whom he was replying) was saying he didn't create
them until they were moused over, but he wasn't destroying them on
mouseout. It was more just a lazy-loading mechanism so that he didn't
create draggables where they would never possibly be used. Makes sense
to me. If you've got a huge number of draggables, and most likely few
or none of them will be used, why use up the memory?
Greg
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
