Regarding DragDrop I am wondering what the deal about Internet Explorer 6 is. My application is near to final and now while testing browsers all but the IE6 are running as supposed to. Any other browser is performing smooth movement while IE compared provides a very bad expirience. I''ve seen some "tuning" infos on this list but they are either outdated or not actually working or helping. Is there anything i could do about it? Is this a known issue or maybe only appears under special circumstances? Some details on the subject would be helpful. Maybe there is a way around it, even it means to sacrifice some functionality. Any help is much appreciated. Thanks in advance - Kjell _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Do you have a ton of draggables on the page at a time (or droppables)? If so, one work around is to "lazy load" the instantiation of the draggable object. That is, only actually make an element draggable at the very point at which dragging functionality is needed (in this case the mouseover event might be the longest you can wait). So, for each element-to-become-draggable, you set up a mouseover listener, which extends the element to become draggable (and also removes itself as a mouseover listener -- you don''t need it past the first instance). If the mouse never goes over an element, it never needs to be a draggable, right? This minimizes the total number of objects in memory, and will reduce the amount of loop processing that goes on during dragging operations. For Droppables, it can be a bit more tricky, but a similar technique can be employed. I''ve also gone as far as to override the dragdrop.js file to include a checkDropRelevance() function which allows me to bypass collision detection (a costly operation) if I know that a certain droppable doesn''t even pertain to my draggable. These techniques will improve overall performance on ALL browsers, though IE may be the most noticeable. I had to engineer this approach in an app which generated an arbitrary number of draggables/droppables (based on number of DB records returns in a DataGrid) -- without it, the dragdrop code is quite inefficient. On 6/15/06, Kjell Bublitz <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Regarding DragDrop > > I am wondering what the deal about Internet Explorer 6 is. My application > is near to final and now while testing browsers all but the IE6 are running > as supposed to. Any other browser is performing smooth movement while IE > compared provides a very bad expirience. I''ve seen some "tuning" infos on > this list but they are either outdated or not actually working or helping. > Is there anything i could do about it? Is this a known issue or maybe only > appears under special circumstances? Some details on the subject would be > helpful. Maybe there is a way around it, even it means to sacrifice some > functionality. Any help is much appreciated. > > Thanks in advance > - Kjell > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Those are really great suggestions Ryan, I can''t wait to incorporate that approach as well ;) -l Ryan Gahl in message Re: [Rails-spinoffs] Why such bad performance with IE ? (Thu, 06/15 12:03):> Do you have a ton of draggables on the page at a time (or droppables)? > > If so, one work around is to "lazy load" the instantiation of the draggable > object. That is, only actually make an element draggable at the very point > at which dragging functionality is needed (in this case the mouseover event > might be the longest you can wait). So, for each > element-to-become-draggable, you set up a mouseover listener, which extends > the element to become draggable (and also removes itself as a mouseover > listener -- you don''t need it past the first instance). If the mouse never > goes over an element, it never needs to be a draggable, right? This > minimizes the total number of objects in memory, and will reduce the amount > of loop processing that goes on during dragging operations. > > For Droppables, it can be a bit more tricky, but a similar technique can be > employed. I''ve also gone as far as to override the dragdrop.js file to > include a checkDropRelevance() function which allows me to bypass collision > detection (a costly operation) if I know that a certain droppable doesn''t > even pertain to my draggable. > > These techniques will improve overall performance on ALL browsers, though IE > may be the most noticeable. > > I had to engineer this approach in an app which generated an arbitrary > number of draggables/droppables (based on number of DB records returns in a > DataGrid) -- without it, the dragdrop code is quite inefficient. > > > > On 6/15/06, Kjell Bublitz <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > >Regarding DragDrop > > > >I am wondering what the deal about Internet Explorer 6 is. My application > >is near to final and now while testing browsers all but the IE6 are running > >as supposed to. Any other browser is performing smooth movement while IE > >compared provides a very bad expirience. I''ve seen some "tuning" infos on > >this list but they are either outdated or not actually working or helping. > >Is there anything i could do about it? Is this a known issue or maybe only > >appears under special circumstances? Some details on the subject would be > >helpful. Maybe there is a way around it, even it means to sacrifice some > >functionality. Any help is much appreciated. > > > >Thanks in advance > >- Kjell > > > >_______________________________________________ > >Rails-spinoffs mailing list > >Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > >> _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs-- Lindsey Simon lsimon-kAMMLXQ8Af9Wk0Htik3J/w@public.gmane.org Key fingerprint = C6A9 B9D9 677E A631 3E7F 43BF 5E2F 77F1 A33C B117 Public Key: http://www.commoner.com/pubkey.asc
Thanks for the explanation. This really sounds interesting. Yes, i am using alot sortables.. not actually in my test enviroment but i aim for scalability (unlimited lists and items shall be possible). I use Sortable.create on unordered lists. Each list item has a ''handle'' and i have setup a ''containment'' to all lists. Then i have around 10 other draggables besides these sortables. These have a seperate menu and are intended to be added to the sortables with drag/drop. code: http://www.bloxpress.org/demo/wp-content/themes/bloxpress2/system/javascript/bloxpress/bp_builder.js I have read your article on "lazy load" method. Even tho i am intermediate on prototype and writing objects i couldn''t think of a way on how to implement your methods to my object. Where do i hook in when creating sortables, draggables and droppables? Do i just call these methods on page load? I would be greatful if you could send me a small "how to use". Best regards, Kjell On 6/15/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Do you have a ton of draggables on the page at a time (or droppables)? > > If so, one work around is to "lazy load" the instantiation of the > draggable object. That is, only actually make an element draggable at the > very point at which dragging functionality is needed (in this case the > mouseover event might be the longest you can wait). So, for each > element-to-become-draggable, you set up a mouseover listener, which extends > the element to become draggable (and also removes itself as a mouseover > listener -- you don''t need it past the first instance). If the mouse never > goes over an element, it never needs to be a draggable, right? This > minimizes the total number of objects in memory, and will reduce the amount > of loop processing that goes on during dragging operations. > > For Droppables, it can be a bit more tricky, but a similar technique can > be employed. I''ve also gone as far as to override the dragdrop.js file to > include a checkDropRelevance() function which allows me to bypass collision > detection (a costly operation) if I know that a certain droppable doesn''t > even pertain to my draggable. > > These techniques will improve overall performance on ALL browsers, though > IE may be the most noticeable. > > I had to engineer this approach in an app which generated an arbitrary > number of draggables/droppables (based on number of DB records returns in a > DataGrid) -- without it, the dragdrop code is quite inefficient. > > > > On 6/15/06, Kjell Bublitz <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Regarding DragDrop > > I am wondering what the deal about Internet Explorer 6 is. My application > is near to final and now while testing browsers all but the IE6 are running > as supposed to. Any other browser is performing smooth movement while IE > compared provides a very bad expirience. I''ve seen some "tuning" infos on > this list but they are either outdated or not actually working or helping. > Is there anything i could do about it? Is this a known issue or maybe only > appears under special circumstances? Some details on the subject would be > helpful. Maybe there is a way around it, even it means to sacrifice some > functionality. Any help is much appreciated. > > Thanks in advance > - Kjell > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
It might not be a bad idea to release a file that overloads the drag-drop stuff with all that, so we can share in the greatness :-) Would it be non-trivial to implement that lazy-loading in a generic enough way that you could do that? Greg ________________________________ From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Ryan Gahl Sent: Thursday, June 15, 2006 11:04 AM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails-spinoffs] Why such bad performance with IE ? Do you have a ton of draggables on the page at a time (or droppables)? If so, one work around is to "lazy load" the instantiation of the draggable object. That is, only actually make an element draggable at the very point at which dragging functionality is needed (in this case the mouseover event might be the longest you can wait). So, for each element-to-become-draggable, you set up a mouseover listener, which extends the element to become draggable (and also removes itself as a mouseover listener -- you don''t need it past the first instance). If the mouse never goes over an element, it never needs to be a draggable, right? This minimizes the total number of objects in memory, and will reduce the amount of loop processing that goes on during dragging operations. For Droppables, it can be a bit more tricky, but a similar technique can be employed. I''ve also gone as far as to override the dragdrop.js file to include a checkDropRelevance() function which allows me to bypass collision detection (a costly operation) if I know that a certain droppable doesn''t even pertain to my draggable. These techniques will improve overall performance on ALL browsers, though IE may be the most noticeable. I had to engineer this approach in an app which generated an arbitrary number of draggables/droppables (based on number of DB records returns in a DataGrid) -- without it, the dragdrop code is quite inefficient. On 6/15/06, Kjell Bublitz <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: Regarding DragDrop I am wondering what the deal about Internet Explorer 6 is. My application is near to final and now while testing browsers all but the IE6 are running as supposed to. Any other browser is performing smooth movement while IE compared provides a very bad expirience. I''ve seen some "tuning" infos on this list but they are either outdated or not actually working or helping. Is there anything i could do about it? Is this a known issue or maybe only appears under special circumstances? Some details on the subject would be helpful. Maybe there is a way around it, even it means to sacrifice some functionality. Any help is much appreciated. Thanks in advance - Kjell _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Hmm, yes. maybe it''s about time a factored that stuff out into a cohesive patch that people can bootstrap into their stuff more easily... I''ll take a look and keep you posted. On 6/15/06, Gregory Hill <Gregory_Hill-l9nu40+TWxQ@public.gmane.org> wrote:> > It might not be a bad idea to release a file that overloads the drag-drop > stuff with all that, so we can share in the greatness J > > > > Would it be non-trivial to implement that lazy-loading in a generic enough > way that you could do that? > > > > Greg > > > ------------------------------ > > *From:* rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto: > rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] *On Behalf Of *Ryan Gahl > *Sent:* Thursday, June 15, 2006 11:04 AM > *To:* rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > *Subject:* Re: [Rails-spinoffs] Why such bad performance with IE ? > > > > Do you have a ton of draggables on the page at a time (or droppables)? > > If so, one work around is to "lazy load" the instantiation of the > draggable object. That is, only actually make an element draggable at the > very point at which dragging functionality is needed (in this case the > mouseover event might be the longest you can wait). So, for each > element-to-become-draggable, you set up a mouseover listener, which extends > the element to become draggable (and also removes itself as a mouseover > listener -- you don''t need it past the first instance). If the mouse never > goes over an element, it never needs to be a draggable, right? This > minimizes the total number of objects in memory, and will reduce the amount > of loop processing that goes on during dragging operations. > > For Droppables, it can be a bit more tricky, but a similar technique can > be employed. I''ve also gone as far as to override the dragdrop.js file to > include a checkDropRelevance() function which allows me to bypass collision > detection (a costly operation) if I know that a certain droppable doesn''t > even pertain to my draggable. > > These techniques will improve overall performance on ALL browsers, though > IE may be the most noticeable. > > I had to engineer this approach in an app which generated an arbitrary > number of draggables/droppables (based on number of DB records returns in a > DataGrid) -- without it, the dragdrop code is quite inefficient. > > > On 6/15/06, *Kjell Bublitz* <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Regarding DragDrop > > I am wondering what the deal about Internet Explorer 6 is. My application > is near to final and now while testing browsers all but the IE6 are running > as supposed to. Any other browser is performing smooth movement while IE > compared provides a very bad expirience. I''ve seen some "tuning" infos on > this list but they are either outdated or not actually working or helping. > Is there anything i could do about it? Is this a known issue or maybe only > appears under special circumstances? Some details on the subject would be > helpful. Maybe there is a way around it, even it means to sacrifice some > functionality. Any help is much appreciated. > > Thanks in advance > > - Kjell > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
I was playing around with the event observe an was finally able to use Ryans method. But here are some thoughts i want to share. Observing mouseover will only help on page load - but it will not improve the draggable performance cause the problem is (as far as the theory goes) that all the draggables are in the memory of IE, kicking.. Now if the draggables fill the memory right on page load OR if they do so one-by-one using mouseover ..i think it doesn''t matter. Now i tried to counter this by creating a second observer which is supposed to reset the draggable on "mouseOut" and "buttonUp". It works pretty well and aims to free up memory this way by destroying the handle. If this really helps is written elsewhere. However. What i really need is something to fix the Sortables with constraint:false, because from my expirience the problem with sortables is the collision detection. It is simple to compare. Just move a sortable item over a sortable list and then do the same outside the list. It is like day and night. I guess that the collision detection tries to apply itself but fails unhandled.. I think a possible fix would be to disable the collision detection anywhere but the list(s) itself. Maybe it is possible to hook in with a single Observer.. i don''t know .. what you think? Ideas? Best regards, Kjell On 6/15/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hmm, yes. maybe it''s about time a factored that stuff out into a cohesive > patch that people can bootstrap into their stuff more easily... I''ll take a > look and keep you posted. > > > On 6/15/06, Gregory Hill <Gregory_Hill-l9nu40+TWxQ@public.gmane.org> wrote: > > > > It might not be a bad idea to release a file that overloads the > > drag-drop stuff with all that, so we can share in the greatness J > > > > > > > > Would it be non-trivial to implement that lazy-loading in a generic > > enough way that you could do that? > > > > > > > > Greg > > > > > > ------------------------------ > > > > *From:* rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto: > > rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] * On Behalf Of *Ryan Gahl > > *Sent:* Thursday, June 15, 2006 11:04 AM > > *To:* rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > *Subject:* Re: [Rails-spinoffs] Why such bad performance with IE ? > > > > > > > > Do you have a ton of draggables on the page at a time (or droppables)? > > > > If so, one work around is to "lazy load" the instantiation of the > > draggable object. That is, only actually make an element draggable at the > > very point at which dragging functionality is needed (in this case the > > mouseover event might be the longest you can wait). So, for each > > element-to-become-draggable, you set up a mouseover listener, which extends > > the element to become draggable (and also removes itself as a mouseover > > listener -- you don''t need it past the first instance). If the mouse never > > goes over an element, it never needs to be a draggable, right? This > > minimizes the total number of objects in memory, and will reduce the amount > > of loop processing that goes on during dragging operations. > > > > For Droppables, it can be a bit more tricky, but a similar technique can > > be employed. I''ve also gone as far as to override the dragdrop.js file > > to include a checkDropRelevance() function which allows me to bypass > > collision detection (a costly operation) if I know that a certain droppable > > doesn''t even pertain to my draggable. > > > > These techniques will improve overall performance on ALL browsers, > > though IE may be the most noticeable. > > > > I had to engineer this approach in an app which generated an arbitrary > > number of draggables/droppables (based on number of DB records returns in a > > DataGrid) -- without it, the dragdrop code is quite inefficient. > > > > > > On 6/15/06, *Kjell Bublitz* <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Regarding DragDrop > > > > I am wondering what the deal about Internet Explorer 6 is. My > > application is near to final and now while testing browsers all but the IE6 > > are running as supposed to. Any other browser is performing smooth movement > > while IE compared provides a very bad expirience. I''ve seen some "tuning" > > infos on this list but they are either outdated or not actually working or > > helping. Is there anything i could do about it? Is this a known issue or > > maybe only appears under special circumstances? Some details on the subject > > would be helpful. Maybe there is a way around it, even it means to sacrifice > > some functionality. Any help is much appreciated. > > > > Thanks in advance > > > > - Kjell > > > > > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > > > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
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:
function (event) {
var d = new Draggable(div, {endeffect: function (element)
{Draggables.clear();} });
d.initDrag(event);
Draggables.updateDrag(event);
}
TAG
On Jun 16, 2006, at 4:41 AM, Kjell Bublitz wrote:
> I was playing around with the event observe an was finally able to
> use Ryans method. But here are some thoughts i want to share.
>
> Observing mouseover will only help on page load - but it will not
> improve the draggable performance cause the problem is (as far as
> the theory goes) that all the draggables are in the memory of IE,
> kicking..
>
> Now if the draggables fill the memory right on page load OR if they
> do so one-by-one using mouseover ..i think it doesn''t matter.
>
> Now i tried to counter this by creating a second observer which is
> supposed to reset the draggable on "mouseOut" and
"buttonUp". It
> works pretty well and aims to free up memory this way by destroying
> the handle. If this really helps is written elsewhere.
>
> However. What i really need is something to fix the Sortables with
> constraint:false, because from my expirience the problem with
> sortables is the collision detection. It is simple to compare. Just
> move a sortable item over a sortable list and then do the same
> outside the list. It is like day and night. I guess that the
> collision detection tries to apply itself but fails unhandled..
>
> I think a possible fix would be to disable the collision detection
> anywhere but the list(s) itself. Maybe it is possible to hook in
> with a single Observer.. i don''t know .. what you think? Ideas?
>
> Best regards,
> Kjell
>
> 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
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 <Gregory_Hill-l9nu40+TWxQ@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
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. :( Regards On 6/16/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <Gregory_Hill-l9nu40+TWxQ@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
..yea, sorry I can''t really say much as far as Sortable optimizations go, as I have yet to use a single Sortable in any project :-) 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 <m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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. :( > > Regards > > > > On 6/16/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 < Gregory_Hill-l9nu40+TWxQ@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > > > > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
I could succesfully add Draggable Lazy Loading to Sortable.create(). But it
didn''t help much.... :(
As i said before the problem lies elsewhere. I also tried to rewrite the
draw function but even if i port all functions used within to local it wont
speed up anything or much.. Here is the changed part of the Sortable create
method:
// added by me
options.dragObservers = [];
(this.findElements(element, options) || []).each( function(e) {
// handles are per-draggable
var handle = options.handle ? Element.childrenWithClassName(e,
options.handle)[0] : e;
// create event callback and add to observer array
options.dragObservers[e] = function() {
Sortable.createDraggableListener(e, options_for_draggable,
options, handle);
}
Event.observe(e, "mouseover", options.dragObservers[e]);
// eom
Droppables.add(e, options_for_droppable);
if(options.tree) e.treeNode = element;
options.droppables.push(e);
});
And finally i added the function createDraggableListener to the class:
createDraggableListener: function(e, options_for_draggable, options,
handle)
{
options.draggables.push( new Draggable(e,
Object.extend(options_for_draggable,
{ handle: handle })) );
Event.stopObserving(e, "mouseover", options.dragObservers[e]);
},
And thats it. You can test it by adding a action or something to
createDraggableListener.
Humm.. so far, so bad.. oh well.. i''ll keep it anyways.
Regards,
Kjell
On 6/16/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
> ..yea, sorry I can''t really say much as far as Sortable
optimizations go,
> as I have yet to use a single Sortable in any project :-)
>
> 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
<m3nt0r.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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. :(
> >
> > Regards
> >
> >
> >
> > On 6/16/06, Ryan Gahl
<ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <
Gregory_Hill-l9nu40+TWxQ@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> > > >
> > >
> > >
> > > _______________________________________________
> > > Rails-spinoffs mailing list
> > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> > >
> > >
> > >
> >
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> >
> >
> >
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs