Slow drag performance when there are a lot of draggables on screen

[reddevil7nine]

We have an app that allows you to search for items that can be dragged
onto a view. when the search result returns a lot of items (500+),
dragging widgets becomes very cumbersome. the initial drag is delayed
heavily (10 seconds+) and when you drag the widget, it's extremely
slow. it might be helpful to mention that the draggables returned by
the search are contained in a scrollable div.

the interesting thing however, is that once you are over a
dropcontroller, the dragging response returns to normal. as soon as
you move off the dropcontroller, response goes back to being slow and
cumbersome.

has anyone else had issues similar to this? is this a bug in the gwt-
dnd or is our app not doing something correctly?

Thank you.

[Carl Rahmström]

We are seeing the same thing except for your "interesting thing". Dragging is slow when you have many widgets and many drop controllers. I would be nice if you could disable some of the "onDragStart" and the "onMove"-features if things get slow. I think you have to make those changes yourself and recompile gwt-dnd. I don't think a simple overwrite will do.

We ended up using one drop controller and getting x and y-cordinates from the drop position.

Carl

--
You received this message because you are subscribed to the Google Groups "gwt-dnd" group.
To post to this group, send email to gwt...@googlegroups.com.
To unsubscribe from this group, send email to gwt-dnd+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gwt-dnd?hl=en.

[Fred Sauer]

Note that development mode is very slow. To see the real app performance, you'll want to compile your application and test in production mode

2012/1/31 Carl Rahmström <ca...@rahmstrom.com>

--
Fred Sauer
fr...@allen-sauer.com

[reddevil7nine]

Carl and Fred, thank you both for the response.

I learned early on with GWT that development mode is slower than
production mode. The issue is in both places; the post i made earlier
describes the production setting.

FYI, we have two permanent drop controllers. Some of the widgets, when
dropped, are constructed as new widgets who may then become drop
targets as well.

Any advice would be greatly appreciated as I'm not sure how to proceed
at this point without potentially rewriting a lot of code.

On Jan 31, 2:32 pm, Fred Sauer <f...@allen-sauer.com> wrote:
> Note that development mode is very slow. To see the real app performance,
> you'll want to compile your application and test in production mode
>

> 2012/1/31 Carl Rahmström <c...@rahmstrom.com>

>
>
>
>
>
>
>
>
>
> > We are seeing the same thing except for your "interesting thing". Dragging
> > is slow when you have many widgets and many drop controllers. I would be
> > nice if you could disable some of the "onDragStart" and the
> > "onMove"-features if things get slow. I think you have to make those
> > changes yourself and recompile gwt-dnd. I don't think a simple overwrite
> > will do.
>
> > We ended up using one drop controller and getting x and y-cordinates from
> > the drop position.
>
> > Carl
>

> >  *
> > *

> f...@allen-sauer.com

[reddevil7nine]

Mr. Sauer, anything?

[Fred Sauer]

I'd try Carl's suggestions, or otherwise limit the the number of targets.

You could reduce the number of widgets by implementing a virtual scroll pane. Let's say the page can display ~20 results at a time. You have 500 results. I typical approach is to actually only create and display 20 widgets at a time. Which 20 out of the 500 are represented on screen depends on the position of the scroll bar. If the user scrolls down 3 results (by moving the virtual scrollbar), then you remove the top three widgets and re-insert than at the bottom of the remaining 17, replacing their representation/contents/text/whatever with results 21, 22 and 23.

fr...@allen-sauer.com

[reddevil7nine]

Thank you for the help, not what i was hoping to hear but you've given
me some ideas.

> f...@allen-sauer.com

[reddevil7nine]

i was looking around trying to come up with a way to resolve all of
this and i noticed something that might be worth pointing out:
in the method:
com.allen_sauer.gwt.dnd.client.DropControllerCollection.getIntersectDropController(int
x, int y)
there is a block of code that loops through the DropController
candidates with what appears it's only purpose being for debugging.

for (int i = sortedCandidates.length - 1; i >= 0; i--) {
Candidate candidate = sortedCandidates[i];
if (DOMUtil.DEBUG) {
DOMUtil.debugWidgetWithColor(candidate.getDropTarget(), "blue");
}
}

subsequent to that, the code then loops through and actually tries to
identify if the x and y coordinates are over a DropController.

From what i can see, that entire block of code should only run if
DOMUtil.DEBUG is true since that's its only purpose. By changing it,
i think there's room for a slight performance improvement, especially
if someone had multiple DropControllers on screen.

I doubt this will “fix” anything for me, but hey, it's something ;)

[Fred Sauer]

I *think* the code in question is compiled out when debugging is disabled.

But just in case, and for when you're running in dev mode, I committed your suggested fix:

  http://code.google.com/p/gwt-dnd/source/detail?r=ba6ebaf4e5e6bb08ed697e745910b8ed4ca47b21

Thanks!

fr...@allen-sauer.com

[Chak Lai]

I try to use RepeatingCommand to relief some workload off in PickupDragController.onDragMove(), and the performance seems improved. 

Note: I renamed the file and object because it is easier for me to test the code.