FLUID-1135: "Begin drag" operation in the Reorderer is too slow

Description

User testing has determined that the slow startup of a drag operation in the reorderer confuses some users and causes them to disbelieve in the affordance of draggability. This should be accelerated so that it can occur well within a perceptual cycle (closer to 100ms than the current near 500ms of the "portal" sample on FF1.x and FF2.x browsers)

http://wiki.fluidproject.org/display/fluid/Layout+Customizer+User+Testing+-+Round+2+Results

Comments

• Antranig Basman commented 2008-08-12T12:55:49.000-0400

  Firefox 2 profiling:

  mouseStart 1 0% 0ms 468.75ms 468.75ms 468.75ms 468.75ms

  setDropEffects 2 0% 0ms 218.75ms 109.375ms 109.375ms 109.375ms
  prepareOffsets 1 0% 0ms 78.125ms 78.125ms 78.125ms 78.125ms

  defaultAvatarCreator 1 0% 0ms 125ms 125ms 125ms 125ms
  helper 1 0% 0ms 125ms 125ms 125ms 125ms

  mouseMove 3 0% 0ms 515.625ms 171.875ms 0ms 500ms

  setDropEffects causes a complete jQuery scan, needs to be cached (20% of startup time)
  prepareOffsets ditto, offsets in general are expensive (nearly 10ms a throw)

  Creating the avatar itself consumes 125ms which will be pretty hard to amortise...
  Interestingly the "clone" operation on the avatar only takes 15ms - probably the "avatar cleansing" can be accelerated a lot (perhaps by attacking the raw DOM in a single scan)

• Antranig Basman commented 2008-08-17T18:13:48.000-0400

  From rev 5353 there is now a "fast cleanse" strategy applied to creating the avatar, which has got creation time below 40ms on FF2. It has been reported that this also resolves FLUID-774. However I am still not happy with the avatar situation since there is now (and has to some extent always been) a "sizing issue" - the avatar does not naturally take up the same size that the same DOM material did in the document (which is not surprising, since we seem to take no care to ensure this). I am noticing this with the Lightbox, which appears "longer and narrower" than its original material, which may be a regression - however, certainly with the "todo list" I am seeing that again the draggable rows are much narrower and this has always been the case.

• Antranig Basman commented 2008-09-08T12:59:49.000-0400

  Since moving away from jQuery offsets, the equivalent of "prepareOffsets" is now around twice as fast -

  updateGeometry 2 0% 0ms 78.125ms 39.063ms 15.625ms 62.5ms GeometricManager.... (line 248)
  computeGeometry 10 0% 0ms 78.125ms 7.813ms 0ms 62.5ms GeometricManager.... (line 189)

  Pending a final burst of optimisation...

• Justin Obara commented 2011-01-10T14:38:27.299-0500

  Appears to have been fixed.