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

Dragdrop perfomance

Expand Messages
  • Peter Michaux
    Hi, I am experimenting with some drag drop functionality similar to the yahoo example http://developer.yahoo.com/yui/examples/dragdrop/targetable.html It seems
    Message 1 of 9 , May 30, 2006
    • 0 Attachment
      Hi,

      I am experimenting with some drag drop functionality similar to the
      yahoo example

      http://developer.yahoo.com/yui/examples/dragdrop/targetable.html

      It seems that during dragging the dragged element follows the cursor
      in a very jerky way. Sometimes the element stays still while my mouse
      moves all around the screen. My guess is that the dragdrop library
      must continuosly check to see if the dragged element is currently
      hovering over a drop zone. That must be a lot of calculation with the
      Dom library getRegion. Is this correct?

      Thanks,
      Peter
    • Adam Moore
      ... Hi Peter, the utility does need to continuously determine if you are dragging over a target. The positions of the drag and drop elements are cached during
      Message 2 of 9 , May 30, 2006
      • 0 Attachment
        On Tue, May 30, 2006 at 03:22:25PM -0700, Peter Michaux wrote:
        > Hi,
        >
        > I am experimenting with some drag drop functionality similar to the
        > yahoo example
        >
        > http://developer.yahoo.com/yui/examples/dragdrop/targetable.html
        >
        > It seems that during dragging the dragged element follows the cursor
        > in a very jerky way. Sometimes the element stays still while my mouse
        > moves all around the screen. My guess is that the dragdrop library
        > must continuosly check to see if the dragged element is currently
        > hovering over a drop zone. That must be a lot of calculation with the
        > Dom library getRegion. Is this correct?

        Hi Peter, the utility does need to continuously determine if you are
        dragging over a target. The positions of the drag and drop elements are
        cached during the drag to minimize the performance impact of this check.

        Without seeing your code, it is difficult to determine the cause of your
        performance issue. Here are a few things you can check:

        * The deeper elements are in the dom the more expensive it is to get and set
        its position. This is why implementations based on DDProxy can
        outperform those based on DD (the proxy element's parent is the body.)

        * The onDrag event fires continuously during the drag. Anything that is
        done in this drag and drop event has the potential to impact drag and drop
        performance.

        * The positions only need to be calculated for drag and drop elements that
        are in the group or groups the dragged element is assigned to. If you
        have a large number of instances, you may be able to improve performance
        by specifying unique groups for items that are not going to interact
        with items you assign to other groups.



        -Adam
      • Peter Michaux
        Hi Adam, Thanks for the information. Guessing your email address maybe you wrote the drag drop library? I have been working with some drag drop libraries for a
        Message 3 of 9 , May 30, 2006
        • 0 Attachment
          Hi Adam,

          Thanks for the information.

          Guessing your email address maybe you wrote the drag drop library? I have been working with some drag drop libraries for a while without success and without the Yahoo! UI dragdrop.js library. Today I started working with the interesting moments in the Yahoo! library. This library (along with the connection and event libraries) is really great! Two hours and my problems are solved. Thanks to the team:)

          Peter



          On 5/30/06, Adam Moore <adamoore@...> wrote:
          On Tue, May 30, 2006 at 03:22:25PM -0700, Peter Michaux wrote:
          > Hi,
          >
          > I am experimenting with some drag drop functionality similar to the
          > yahoo example
          >
          > http://developer.yahoo.com/yui/examples/dragdrop/targetable.html
          >
          > It seems that during dragging the dragged element follows the cursor
          > in a very jerky way. Sometimes the element stays still while my mouse
          > moves all around the screen. My guess is that the dragdrop library
          > must continuosly check to see if the dragged element is currently
          > hovering over a drop zone. That must be a lot of calculation with the
          > Dom library getRegion. Is this correct?

          Hi Peter, the utility does need to continuously determine if you are
          dragging over a target.  The positions of the drag and drop elements are
          cached during the drag to minimize the performance impact of this check.

          Without seeing your code, it is difficult to determine the cause of your
          performance issue.  Here are a few things you can check:

          * The deeper elements are in the dom the more expensive it is to get and set
            its position.  This is why implementations based on DDProxy can
            outperform those based on DD (the proxy element's parent is the body.)

          * The onDrag event fires continuously during the drag.  Anything that is
            done in this drag and drop event has the potential to impact drag and drop
            performance.

          * The positions only need to be calculated for drag and drop elements that
            are in the group or groups the dragged element is assigned to.  If you
            have a large number of instances, you may be able to improve performance
            by specifying unique groups for items that are not going to interact
            with items you assign to other groups.



          -Adam


          SPONSORED LINKS
          C programming language Computer programming languages Java programming language
          The c programming language C programming language Concept of programming language


          YAHOO! GROUPS LINKS




        • Peter Michaux
          ... Here is another idea I started using today to inprove performance. I have many draggable items in group Employee and only two drop targets in group
          Message 4 of 9 , May 31, 2006
          • 0 Attachment
            On 5/30/06, Adam Moore <adamoore@...> wrote:
            >
            > * The positions only need to be calculated for drag and drop elements that
            > are in the group or groups the dragged element is assigned to. If you
            > have a large number of instances, you may be able to improve performance
            > by specifying unique groups for items that are not going to interact
            > with items you assign to other groups.

            Here is another idea I started using today to inprove performance. I
            have many draggable items in group Employee and only two drop targets
            in group Employee. When I create each draggable I let it be added to
            the default group (it is not in Employee). When I create each drop
            target I add it to group Employee (it is not in default).

            When a draggable item has a mouse down event I add it to group
            Employee and remove it from the default group (using delete
            this.groups['default']). When this draggable has a mouse up even i
            change it back to the default group. This way I never have more than
            three objects in group Employee at a time. This could mean avoiding
            maybe one hundred other possible group interactions.

            It would be nice to have in the library a removeFromGroup() method to
            compliment addToGroup().

            This also implies the library could have a DDDraggable class which is
            something that can only be dragged and never a target. This would
            automatically change groups on mouse down and up events. DDDraggable
            would compliment DDTarget. A possibility for the future?

            Peter
          • Peter Michaux
            HI, I don t know where I should submit documentation errors but I found this in the dragdrop code // initialize the groups array this.groups = {}; Should say
            Message 5 of 9 , May 31, 2006
            • 0 Attachment
              HI,

              I don't know where I should submit documentation errors but I found
              this in the dragdrop code

              // initialize the groups array
              this.groups = {};

              Should say object not array.

              Peter
            • Matt Warden
              ... They are using SourceForge to track bugs, and I have used it for documentation errors before. http://sf.net/tracker/?group_id=165715&atid=836476 You can
              Message 6 of 9 , May 31, 2006
              • 0 Attachment
                On 5/31/06, Peter Michaux <petermichaux@...> wrote:
                > HI,
                >
                > I don't know where I should submit documentation errors but I found
                > this in the dragdrop code
                >
                > // initialize the groups array
                > this.groups = {};
                >
                > Should say object not array.

                They are using SourceForge to track bugs, and I have used it for
                documentation errors before.

                http://sf.net/tracker/?group_id=165715&atid=836476

                You can also get to here by going to sf.net/projects/yui and clicking on 'bugs'

                --
                Matt Warden
                Oxford, OH, USA
                http://mattwarden.com


                This email proudly and graciously contributes to entropy.
              • Nige White
                ... The boolean isTarget can be set to false, then the DD instance is not a target. I think that the pattern used by the YAHOO DragDrop library might be
                Message 7 of 9 , Jun 1, 2006
                • 0 Attachment
                  Peter Michaux wrote:

                  >On 5/30/06, Adam Moore <adamoore@...> wrote:
                  >
                  >
                  >> * The positions only need to be calculated for drag and drop elements that
                  >> are in the group or groups the dragged element is assigned to. If you
                  >> have a large number of instances, you may be able to improve performance
                  >> by specifying unique groups for items that are not going to interact
                  >> with items you assign to other groups.
                  >>
                  >>
                  >
                  >Here is another idea I started using today to inprove performance. I
                  >have many draggable items in group Employee and only two drop targets
                  >in group Employee. When I create each draggable I let it be added to
                  >the default group (it is not in Employee). When I create each drop
                  >target I add it to group Employee (it is not in default).
                  >
                  >When a draggable item has a mouse down event I add it to group
                  >Employee and remove it from the default group (using delete
                  >this.groups['default']). When this draggable has a mouse up even i
                  >change it back to the default group. This way I never have more than
                  >three objects in group Employee at a time. This could mean avoiding
                  >maybe one hundred other possible group interactions.
                  >
                  >It would be nice to have in the library a removeFromGroup() method to
                  >compliment addToGroup().
                  >
                  >This also implies the library could have a DDDraggable class which is
                  >something that can only be dragged and never a target. This would
                  >automatically change groups on mouse down and up events. DDDraggable
                  >would compliment DDTarget. A possibility for the future?
                  >
                  >

                  The boolean isTarget can be set to false, then the DD instance is not a
                  target.

                  I think that the pattern used by the YAHOO DragDrop library might be
                  slightly flawed.

                  To me, there should be a difference between a draggable object, and a
                  target object.

                  The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
                  be delivered to the draggable (as now), *and* the target. The target
                  should get to decide what kind of action needs to be taken. The
                  draggable probably doesn't know enough to actually implement any of
                  these handlers. The *target* would do drop position highlighting, change
                  the cursor type to indicate whether drop is possible, and handle the
                  drop event creating a new object, and HTMLElement of it's own choosing.

                  I have implemented this pattern on top of the current library in my
                  DDTreeView/Draggable implementation, but I think that should be the
                  pattern the library uses.

                  The target will probably be a user-written object with methods of its
                  own, so what's needed is an "interface" consisting of the four methods
                  mentioned above - and a getElement() method to get the HTMLElement for
                  which mousemove/mouseup event handlers are needed. Shame such things
                  don't exist in javascript. You should be able to register your target
                  objects with the DragDropMgr to receive events. Then as long as that
                  registered object implements the event handling methods (implements the
                  interface), your target object can react to drags and drops.

                  I'll add an enhancement request.

                  Nige

                  _____________________________________________________________________
                  This message has been checked for all known viruses. Virus scanning
                  powered by Messagelabs http://www.messagelabs.com For more information
                  e-mail : hostmaster@...
                • Peter Michaux
                  ... Thanks for the info. I ll try this. So when I am dragging the libary only looks for interactions with possible targets? That would be nice and efficient
                  Message 8 of 9 , Jun 1, 2006
                  • 0 Attachment
                    > The boolean isTarget can be set to false, then the DD instance is not a
                    > target.

                    Thanks for the info. I'll try this. So when I am dragging the libary
                    only looks for interactions with possible targets? That would be nice
                    and efficient like I was trying for with the groups games I was
                    playing.

                    > I think that the pattern used by the YAHOO DragDrop library might be
                    > slightly flawed.
                    >
                    > To me, there should be a difference between a draggable object, and a
                    > target object.
                    >
                    > The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
                    > be delivered to the draggable (as now), *and* the target. The target
                    > should get to decide what kind of action needs to be taken. The
                    > draggable probably doesn't know enough to actually implement any of
                    > these handlers. The *target* would do drop position highlighting, change
                    > the cursor type to indicate whether drop is possible, and handle the
                    > drop event creating a new object, and HTMLElement of it's own choosing.
                    >
                    > I have implemented this pattern on top of the current library in my
                    > DDTreeView/Draggable implementation, but I think that should be the
                    > pattern the library uses.

                    I agree it seems a little strange but I don't think it is a disaster.
                    In my onDragEnter, onDragOut etc methods I have some "hey you" calls
                    to get the target to pay attention. Things like

                    Draggable.prototype.onDragEnter = function(e, id) {
                    YAHOO.util.getDDById(id).heyYou();
                    //..do other stuff
                    };

                    If the onDragEnter was delivered to the both the draggable and the
                    target then which one will fire first? It might be better the way it
                    is so that we can know the order things happen. I'm curious how you
                    did implement it however.

                    For you draggabble tree, did you make it so that items in an
                    individual node can be reordered or just that items can be moved from
                    node to node. I am looking at sortable lists too and will have to do
                    something different than the Yahoo! example. I don't want the
                    individual items to be targets. I want the node to be the target since
                    the node's HTMLelement might be much bigger than the few elements
                    inside.

                    Peter
                  • Nige White
                    ... I do it in a similar way. In my example at https://secure0.forward-comp.co.uk/yui/examples/treeview/fcl.html I implement onDragEnter, onDrag, onDragDrop
                    Message 9 of 9 , Jun 1, 2006
                    • 0 Attachment
                      Peter Michaux wrote:

                      >> The boolean isTarget can be set to false, then the DD instance is not a
                      >> target.
                      >>
                      >>
                      >
                      >Thanks for the info. I'll try this. So when I am dragging the libary
                      >only looks for interactions with possible targets? That would be nice
                      >and efficient like I was trying for with the groups games I was
                      >playing.
                      >
                      >
                      >
                      >> I think that the pattern used by the YAHOO DragDrop library might be
                      >> slightly flawed.
                      >>
                      >> To me, there should be a difference between a draggable object, and a
                      >> target object.
                      >>
                      >> The drag events (onDragEnter, onDrag, onDragDrop and onDragOut) should
                      >> be delivered to the draggable (as now), *and* the target. The target
                      >> should get to decide what kind of action needs to be taken. The
                      >> draggable probably doesn't know enough to actually implement any of
                      >> these handlers. The *target* would do drop position highlighting, change
                      >> the cursor type to indicate whether drop is possible, and handle the
                      >> drop event creating a new object, and HTMLElement of it's own choosing.
                      >>
                      >> I have implemented this pattern on top of the current library in my
                      >> DDTreeView/Draggable implementation, but I think that should be the
                      >> pattern the library uses.
                      >>
                      >>
                      >
                      >I agree it seems a little strange but I don't think it is a disaster.
                      >In my onDragEnter, onDragOut etc methods I have some "hey you" calls
                      >to get the target to pay attention. Things like
                      >
                      >Draggable.prototype.onDragEnter = function(e, id) {
                      > YAHOO.util.getDDById(id).heyYou();
                      > //..do other stuff
                      >};
                      >
                      >If the onDragEnter was delivered to the both the draggable and the
                      >target then which one will fire first? It might be better the way it
                      >is so that we can know the order things happen. I'm curious how you
                      >did implement it however.
                      >
                      >For you draggabble tree, did you make it so that items in an
                      >individual node can be reordered or just that items can be moved from
                      >node to node. I am looking at sortable lists too and will have to do
                      >something different than the Yahoo! example. I don't want the
                      >individual items to be targets. I want the node to be the target since
                      >the node's HTMLelement might be much bigger than the few elements
                      >inside.
                      >
                      I do it in a similar way. In my example at
                      https://secure0.forward-comp.co.uk/yui/examples/treeview/fcl.html

                      I implement onDragEnter, onDrag, onDragDrop and onDragOut in my
                      DDTreeView. When I construct the DDTarget for this, I override those
                      methods in the DDTarget to call the corresponding events in the scope of
                      the DDTreeView, so it's as if the DDTreeView *is* the target:

                      // Make the tree droppable on. Extend this DDTreeView object to
                      look like a DDTarget.
                      this.ddTarget = new YAHOO.util.DDTarget(this.id, "menuTree");
                      var _this = this;
                      this.ddTarget.onDragEnter = function()
                      {
                      _this.onDragEnter.apply(_this, arguments);
                      };
                      this.ddTarget.onDragOver = function()
                      {
                      _this.onDragOver.apply(_this, arguments);
                      };
                      this.ddTarget.onDragDrop = function()
                      {
                      return _this.onDragDrop.apply(_this, arguments);
                      };
                      this.ddTarget.onDragOut = function()
                      {
                      _this.onDragOut.apply(_this, arguments);
                      };

                      It's a bit like my idea of being able to register any object as a
                      DDTarget (as long as they implement these methods).

                      The Draggable object (an extension of DDProxy) delivers the event, and
                      itself to the target (the DDTreeView) on each of these events:

                      /**
                      This informs the recipient that it has been dropped upon.
                      @return The object created as a result of the drop. It will be null
                      if the target does not accept
                      the drop.
                      */
                      Draggable.prototype.onDragDrop = function(e, id)
                      {
                      this.target = ((typeof id == "string") ?
                      YAHOO.util.DragDropMgr.getDDById(id) : id[0]);
                      return this.target.onDragDrop(e, this);
                      };


                      Nige

                      _____________________________________________________________________
                      This message has been checked for all known viruses. Virus scanning
                      powered by Messagelabs http://www.messagelabs.com For more information
                      e-mail : hostmaster@...
                    Your message has been successfully submitted and would be delivered to recipients shortly.