Community
Participate
Working Groups
I have a gef diagram with a set of edit parts arranged in a grid. When dragging a selection box, GraphicalNodeEditPolicy.getTargetEditPart() gets called on many of my parts which are no where near the mouse. This happens seemingly at random. So far, I haven't been able to track down which code is being called because of the interactive nature. This has a huge performance impact on dragging a selection and is making the diagram very hard to use.
I have more information about this. This is happening in the MarqueeDragTracker. First, I was wrong, not just a few parts, but ALL children of the root are iterated through each time (in calculateNewSelection) the threshold is passed, which I believe is 1 pixel, during a drag. Since feedback doesn't get shown until after the drag is completed, this seems like a huge waste and really slows down when there are lots parts as I have. If I can get a patch considered for 3.3, I would really like to help with this problem. Also, I would like to get some confirmation from more experienced GEFers that this is an issue and fixing it won't negatively impact things elsewhere.
I've noticed this too. Feedback is sent, but it isn't descriptive enough to show the proper effects. The calculation is brute force, which is expensive for large diagrams. We plan on solving this in our product and then seeing if the solution can be pushed back up to GEF itself. It's easy to write your own marquee drag tracker than does top-down search of the figure tree and prunes the tree correctly as it goes.
(In reply to comment #2) Thanks Randy. I came to that same conclusion. As I said, I would also be glad to contribute something if it can get it before you guys have a chance to look at it and push it back up.
Created attachment 214038 [details] improved performance of marquee drag
Created attachment 214039 [details] logic diagram on which first performance test was done
Proposed patch to improve the performance of marquee selection. I added a preliminary filter so that only edit parts that are inside or intersect with the marquee rectangle pass it. This filter is not done for connections. The filter reduces the amount of edit parts for which the getTargetEditPart and isSelectable methods are invoked. Since both of this methods user implemented, I think it is best to only call them when necessary. A future improvement for the patch can include similar treatment for connections (more complicated to implement). The patch was tested on eclipse indigo build 20110916-0149, windows 7. I tested the patch on two different examples of the logic diagram, one with a large number of elements but no depth (7202 OR gates) and the other with some levels of depth (at leas 8 levels of circuits inside circuits, 12968 edit parts not including connections). I measured the average time it took to execute method calculatePrimaryMarqueeSelectedEditParts. Test 1: Old time: 25ms New time: 7.5ms Test 2: (greater improvement since edit parts outside the marquee are filtered on the first pass, filtering also all internal edit parts) Old time: 55ms New time: 0.65ms (!!!) The diagram used for the second test can be found here: http://wikisend.com/download/501342/performance2.logic
(In reply to comment #6) > Proposed patch to improve the performance of marquee selection. > I added a preliminary filter so that only edit parts that are inside or > intersect with the marquee rectangle pass it. This filter is not done for > connections. > The filter reduces the amount of edit parts for which the getTargetEditPart and > isSelectable methods are invoked. Since both of this methods user implemented, > I think it is best to only call them when necessary. > > A future improvement for the patch can include similar treatment for > connections (more complicated to implement). > > The patch was tested on eclipse indigo build 20110916-0149, windows 7. > > I tested the patch on two different examples of the logic diagram, one with a > large number of elements but no depth (7202 OR gates) and the other with some > levels of depth (at leas 8 levels of circuits inside circuits, 12968 edit parts > not including connections). I measured the average time it took to execute > method calculatePrimaryMarqueeSelectedEditParts. > > Test 1: > Old time: 25ms > New time: 7.5ms > > Test 2: (greater improvement since edit parts outside the marquee are filtered > on the first pass, filtering also all internal edit parts) > Old time: 55ms > New time: 0.65ms (!!!) > > The diagram used for the second test can be found here: > http://wikisend.com/download/501342/performance2.logic Thanks for the contribution. However, I am not able to consume the patch properly, as it is not in Git format. Can you please create a Git patch as described in the contribution guide (http://wiki.eclipse.org/GEF_Contributor_Guide)?
Github commit: https://github.com/vainolo/gef/commit/81af08c02571aecbc54ddb44ea83d5ca96902bb3
