Search and Top Navigation
#4410 closed enhancement (notabug)
Opened March 27, 2009 10:54PM UTC
Closed August 22, 2009 01:39PM UTC
Last modified January 17, 2010 06:05AM UTC
Super major speed enhancement for sortable with large lists
Reported by: | cardmagic | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.8 |
Component: | ui.sortable | Version: | 1.7.1 |
Keywords: | speed performance sortable | Cc: | |
Blocked by: | Blocking: |
Description
After much digging around, I found a mis-placed call to _refreshItems which significantly slows down sortables with large numbers of items. _refreshItems does not need to be called during the movement of items as it is currently, but rather it should be called as soon as it has reached a new location. Attached is a patch.
Attachments (1)
Change History (5)
Changed March 27, 2009 11:16PM UTC by comment:1
Changed March 27, 2009 11:52PM UTC by comment:2
Replying to [comment:1 cardmagic]:
Found a bug in speed.patch... but found a work-around... will submit shortly as speed2.patch
When someone moved the refreshItems call to mouseCapture, it seriously slowed down the entire repositioning, so I moved it back to the _mouseStart method.
Changed March 27, 2009 11:53PM UTC by comment:3
Instead of naming the patch speed2.patch, I just replaced speed.patch with the correct patch file
Changed May 07, 2009 12:54PM UTC by comment:4
milestone: | TBD → 1.8 |
---|
Performance improvements are welcome. Patch needs testing.
Changed August 22, 2009 01:39PM UTC by comment:5
resolution: | → invalid |
---|---|
status: | new → closed |
Patch isn't working, since this move from mouseCapture to mouseStart heavily destroys some functionality: If you add new elements to a sortable list, say via an ajax call, they're automatically valid draggables because of the check being there in mouseCapture already - if it wouldn't, they wouldn't be considered a target, and therefore the drag fails.
Found a bug in speed.patch... but found a work-around... will submit shortly as speed2.patch