Loading ...
Sorry, an error occurred while loading the content.

2362Re: [ydn-javascript] research: why YUI dragdrop is so slow

Expand Messages
  • Peter Michaux
    Jun 17, 2006
    • 0 Attachment
      Hi Tim,

      On 6/17/06, Tim Hosking <tim@...> wrote:
      > > What I was trying to get at is why do you have to cache 1000 element
      > > locations and/or regions. You only need to cache the items you will
      > > drag and their possible targets. Could you somehow rework the problem
      > > so this is just a few things at the start of each drag?
      >
      > Because there may be 1000 draggable items. I'm not doing the caching,
      > YUI is.

      Are all 1000 draggables targets? You have set isTarget = false? If YUI
      dragdrop is caching non-target draggables i think that needs to be
      changed. It is unnecessary. You could always override some method in
      the library and submit a patch.


      > > This would require creative CSS. I haven't tried this yet but maybe
      > > you could use the clipping and/or overflow control features of CSS.
      > > Put some of the things you want to clone in each of the four donut
      > > divs and then when the donut is assembled things would look normal
      > > with a one or more pixel hole in the middle. That is my idea anyway.
      >
      >
      > The only problem I can see with this is that you would have to make
      > the dragged object jump shift at the start off the drag to align the
      > hole with the mouse cursor. This may not look so bad with a small,
      > squarish object, but with a long, narrow object, like a line of
      > textual data, the jump could be significant, and make it look really
      > jerky.

      There is no need for the jump shift. The hole does not have to be
      centered in the donut. It can be close to one corner if that is where
      you mousedowned on the original element. This is a be-creative
      situation. Only the whole has to be under the cursor. Otherwise the
      donut proxy can look like anything.


      > > Here is an
      > > example that shows that the mouseover event does not fire while
      > > dragging an element under the cursor.
      > >
      > > http://peter.michaux.ca/examples/donut-dragdrop/event-test.html
      > >
      > > That example convinces me that the mouseover doesn't fire.
      >
      >
      > Interesting. I notice you use YAHOO.util.DD. I just changed my code
      > to use it, and as you say, I don't see mouseover events. I have been
      > using YAHOO.util.DragProxy, and guess what. Yep, it *does* generate
      > the mouseover events .... try it.

      It doesn't for me

      http://peter.michaux.ca/examples/donut-dragdrop/event-test-proxy.html


      > Obviously DD & DragProxy are doing
      > things differently,

      They are both dragging an element under the cursor. That is the
      similarity for detecting events.


      > one of which is not good. Here's a suggestion.
      >
      > Create a subclass of YAHOO.util.DragProxy and override startDrag() to
      > do something like this:-
      >
      > var proxy = this.getDragEl();
      > var len = proxy.childNodes.length;
      >
      > for(var i = 0; i < len; i++) {
      > proxy.removeChild( proxy.childNodes[ i ] );
      > }
      >
      > var element = this.getEl().cloneNode( true );
      > proxy.style.border = "";
      > proxy.style.borderStyle = "none";
      > proxy.appendChild( element );
      >

      This still doesn't work for me

      http://peter.michaux.ca/examples/donut-dragdrop/event-test-proxy2.html

      Can you post a complete HTML document that shows this working in a
      compact example?


      > > The dragdrop library always holds the id's of all draggable elements.
      > > refreshCache should not have to look for these items.
      > >
      > > refreshCache calls getLocation which calls getEl. If you haven't
      > > called getEl for each draggable yet then maybe that is taking some
      > > time: all the document.getElementById() calls. You could do this after
      > > each draggable instance is created. As part of your Draggable subclass
      > > constructor. I think Draggable's constructor should do this anyway.
      > > Probably the getXY call in getLocation is the really slow problem. If
      > > you know the geography of your list items (height etc) perhaps you
      > > could do getXY for the first element and then just increment these
      > > values for the others in the list
      >
      >
      > Aha! That actually worked! Thank you! What a stupid problem :-)

      I'm glad it worked.

      This is more evidence to me that since dragdrop was not an intended
      feature in browsers that we have to be very creative to make it work
      well in difficult situations. This includes situations with many
      targets or overlapping or nested targets.

      Peter
    • Show all 15 messages in this topic