Summary: | Ensure adapters are disposed at once during disposal of a viewer (bulk change) | ||
---|---|---|---|
Product: | [Tools] GEF | Reporter: | Matthias Wienand <matthias.wienand> |
Component: | GEF MVC | Assignee: | gef-inbox <gef-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | mmarchand |
Version: | 5.1.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Matthias Wienand
2019-06-28 10:02:11 EDT
To add some more context here... from my post in the GEF5 forums https://www.eclipse.org/forums/index.php?t=post&reply_to=1808682& !hen I destroy my editor. As each Node's parent is set to null, the InfiniteCanvasViewer calls AdapterSupport.unsetAdapter(). The thing is, AdapterSupport.unsetAdapter() is not a very efficient way to remove 6500 adapters since it walks the list for each adapter that it removes: // process all keys and remove those pointing to the given adapter for (AdapterKey<?> key : new HashMap<>(adapters).keySet()) { if (adapters.get(key) == adapter) { adapters.remove(key); } } That means a for loop of 6500, then a for loop of 6499 for the next element... and so on, until finally all the adapters have been removed. Interestingly enough, the AdapterSupport method dispose will eventually call adapters.remove() for us anyways. My workaround for this was a little bit unfortunate, needed a custom InfiniteCanvasViewer and a custom AdapterSupport that can be deactivated so that it does not try to "process all keys and remove those pointing to the given adapter" since it is deactivated, we can expect an upcoming disposal, which will do that work much more efficiently for us. |