Bug 264587 - Erase is not working properly for BorderedNodeFigure's
Summary: Erase is not working properly for BorderedNodeFigure's
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.2   Edit
Assignee: Alex Boyko CLA
QA Contact:
URL:
Whiteboard: 2.1.4 Patch
Keywords:
: 270962 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-11 15:17 EST by Adam Neal CLA
Modified: 2010-07-19 12:30 EDT (History)
5 users (show)

See Also:


Attachments
proposed patch for 2.2 (60.41 KB, patch)
2009-03-03 12:50 EST, Alex Boyko CLA
no flags Details | Diff
proposed patch cleaned up (5.56 KB, patch)
2009-03-05 10:48 EST, Alex Boyko CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Neal CLA 2009-02-11 15:17:34 EST
Build ID:  M20090127-1710

Steps To Reproduce:
1)The background color of a port was changed to be green.
2)The port is not being painted on the diagram

Seems that the parent's parent's erase function needs to be called in order for the port to properly refresh itself.
Comment 1 Anthony Hunter CLA 2009-02-11 15:43:20 EST
we can fix for 2.2 M6, not the maintenance stream.
Comment 2 Adam Neal CLA 2009-02-11 18:12:12 EST
We have a workaround, so that is fine with us.
Comment 3 Alex Boyko CLA 2009-03-02 17:28:43 EST
The problem is not specific to BorderedNodeFigure but rather to any border item. Since border items are not necessarily instances of BorderedNodeFigure, but could be any figure inside BorderItemContainerFigure.
Problem is really conceptual differences between GEF and GMF. GEF assumes that child figures are strictly inside the bounds of the parent while GMF has a concept of ExtendedBounds which includes children and border items.
Conceptual differences are reflected in the way GEF paints dirty regions by the Update Manager. BorderItemContainerFigure never has meaningful bounds... bounds of BorderItemContainerFigure don't contain and don't intersect with any of its children... but has valid ExtendedBounds...
I'll try to address the problem with fixes to ToggleUpdateManager in GMF and extension hooks in draw2d DeferredUpdateManager.
Comment 4 Alex Boyko CLA 2009-03-03 12:50:13 EST
Created attachment 127348 [details]
proposed patch for 2.2

If I fix ToggleUpdateManager to support IExpandableFigure in repairDamage() method, I'd have to cast figures to IExpandableFigure to get exetended bounds, which seems expensive.
Therefore, I decided to return a wrapper of the update manager in BorderItemContainerFigure#getUpdateManager(). The wrapper overrides #addDirtyRegion(IFigure, int, int, int, int) method and translates the dirty region of a BorderItemContainerFigure child to the parent of BorderedNodeFigure (equivalent to getParent().getParent() that used be called in repaint and erase), to trigger paint of a BorderedNodeFigure, but not the whole figure, but only its region containing the border item. I also, updated, repint and erase methods - update manger wrapper will do the work these methods used to do themselves.

Adam, would you be able to try this patch?
Comment 5 Alex Boyko CLA 2009-03-05 10:48:44 EST
Created attachment 127665 [details]
proposed patch cleaned up

Cleaned up patch
Comment 6 Alex Boyko CLA 2009-03-31 14:45:59 EDT
Hi James,

Could you let me know how this patch is working for border item painting issues you've been noticing?
Yes, it works ok, could you code review the patch please?
Thanks in advance.
Comment 7 Anthony Hunter CLA 2009-04-22 21:05:02 EDT
(In reply to comment #6)
> Hi James,
> 
> Could you let me know how this patch is working for border item painting issues
> you've been noticing?
> Yes, it works ok, could you code review the patch please?
> Thanks in advance.
> 

Hi James, was the patch ok?
Comment 8 James Bruck CLA 2009-04-23 09:48:58 EDT
My apologies for the late reply ... I'm evaluating the patch now.
Comment 9 James Bruck CLA 2009-04-23 09:54:26 EDT
The patch looks good.  Did you also evaluate performance? 
Comment 10 Alex Boyko CLA 2009-04-23 13:35:34 EDT
No I didn't evaluate the performance yet. Good thing you mentioned that... I'll check the performance before committing this.
Comment 11 Alex Boyko CLA 2009-04-24 15:13:15 EDT
*** Bug 270962 has been marked as a duplicate of this bug. ***
Comment 12 Alex Boyko CLA 2009-04-24 15:16:56 EDT
Measured the time to open the diagram with > 400 ports and 400 floating port labels. The time either remain the same or dropped by a second. Without the fix took 10-11 sec. with this fix took 9-10 sec.

Committed the fix to head and maintenance. 
Comment 13 Eclipse Webmaster CLA 2010-07-16 23:35:38 EDT
[target cleanup] 2.2 M7 was the original target milestone for this
bug
Comment 14 Eclipse Webmaster CLA 2010-07-19 12:30:33 EDT
[GMF Restructure] Bug 319140 : product GMF and component
Runtime Diagram was the original product and component for this bug