Bug 250018 - BorderedNodeFigure#layout() may cause infinite loop
Summary: BorderedNodeFigure#layout() may cause infinite loop
Status: RESOLVED FIXED
Alias: None
Product: GMF-Runtime
Classification: Modeling
Component: General (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows XP
: P3 normal
Target Milestone: 2.1.3   Edit
Assignee: Alex Boyko CLA
QA Contact:
URL:
Whiteboard: 2.1.2 Patch
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-07 15:52 EDT by Alex Boyko CLA
Modified: 2010-07-19 12:27 EDT (History)
4 users (show)

See Also:


Attachments
proposed patch (1.05 KB, patch)
2008-10-14 13:37 EDT, Alex Boyko CLA
no flags Details | Diff
proposed patch (1.38 KB, patch)
2008-12-18 20:18 EST, Alex Boyko CLA
aboyko: review?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Boyko CLA 2008-10-07 15:52:15 EDT
BorderedNodeFigure#layout() calls invalidateTree() and erase() regardless whether the bounds of the figure have changed or not.
We need to look into the possibility of calling invalidateTree() if bounds have changed. Perhaps, we shouldn't even call invalidateTree() at all, since border item container acts as a free form figure now.
Comment 1 Alex Boyko CLA 2008-10-14 13:37:43 EDT
Created attachment 115068 [details]
proposed patch

Here is my final version of the patch-fix. Tested manually and with JUnits.
Still need to call invalidateTree() such that border items of border items are re-layed out too (border items labels for example)
Comment 2 Anthony Hunter CLA 2008-10-21 17:27:09 EDT
OK, we are good to commit this to 2.1.3 and 2.2.
Comment 3 Alex Boyko CLA 2008-10-22 09:53:42 EDT
Committed the fix for 2.1.3 and 2.2
Comment 4 Alex Boyko CLA 2008-12-18 17:05:42 EST
The fix introduced a huge performance regression. So reopening to come up with a better fix.
Comment 5 Alex Boyko CLA 2008-12-18 20:18:37 EST
Created attachment 120906 [details]
proposed patch

Moved invalidateTree() inside the if. Ensured that number of calls to #invalidate() and #layout() stayed the same as in 2.1 initially.
Comment 6 Alex Boyko CLA 2008-12-19 11:08:11 EST
Hi Steve, if the new proposed patch looks good to you, I'll commit for 2.1.3. Thanks.
Comment 7 Anthony Hunter CLA 2008-12-19 13:48:27 EST
Patch looks good
Comment 8 Alex Boyko CLA 2008-12-19 15:30:52 EST
Patch committed for 2.1.3 and 2.2
Comment 9 Adam Neal CLA 2009-02-11 13:55:26 EST
This solution breaks the show/hide target feedback mechanism to an extent. 

Our tool is setting the color of port figures to indicate compatibility while the user is creating a connector from another port. The show/hide feedback mechanism triggers the coloring changes. However, with this fix, it seems that the figure is not properly refreshing itself.  Instead even though the color of the figure is set and the figure is re-validated, the coloring change does not always appear

e.g. Sometimes selecting the edit part or its parent edit part, or moving the parent or itself will trigger the figure coloring to start working...

By reverting this fix, I confirmed that the figure refreshing problem disappears, and coloring works consistently again.
Comment 10 Adam Neal CLA 2009-02-11 15:22:32 EST
My previous comments should be ignored for this bug.

This fix has simply identified another problem which had, to this point, gone unnoticed.  I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=264587  to track this issue.  
Comment 11 Eclipse Webmaster CLA 2010-07-19 12:27:54 EDT
[GMF Restructure] Bug 319140 : product GMF and component
Runtime Diagram was the original product and component for this bug