Community
Participate
Working Groups
1. Create a wire between two logic elements on the diagram. 2. Drag the middle point of the wire to create a bend point with 100% zoom. The bend point is moved normally and when the mouse button is released the wire stays exactly the same as at the moment before the button was released. Now, change the zoom to 53% and perform the same operation to the bend point. You should notice that the connection jumps a little bit when the mouse button is released. Problem: dimensions stored by RelativeBendpoint are relative to the connection figure. When the calculation of a bend point location is done these dimensions are translated to absolute coordinates and, hence, with a non-integer scaling factor, a loss of precision occurs. Therefore, the point we get in absolute coordinates translated back to relative coordinates will be a bit off its real location. Suggestion: create precision points from connection anchor reference points, translate them relative to connection. Perform the calculation to locate the bend point with weight and dimensions and return a PrecisionPoint for the location. This will reduce the slight precision error. Patch to be attached
Created attachment 84746 [details] Patch for RelativeBendpoint The patch for RelativeBendpoint with a fix described in the previous comment. This issue affects GMF, because it has a concept of MapMode (HiMetrics) which introduces another non-integer scaling factor aside zoom. Randy, Pratik is it ok for this fix to be committed? Thanks in advance.
Created attachment 85012 [details] patch Previous patch was not uploaded correctly. Here is the correctly uploaded patch. Sorry for any inconvenience.
Created attachment 85584 [details] Uses internally PrecisionDimension This patch work if the PrecisionDimension copy constructor has been fixed. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=213495 Uses internally PrecisionDimension
Perhaps, we'd like to support PrecisionDimension in RelativeBendpoint? In this case, I could modify the visibility of preciseX(),...,preciseHeight() methods on Point, Dimension, Rectangle to public - the patch for bug 212460 Hence, the patch for this one will be modified accordingly.
Missed M5, so moving to M6
(In reply to comment #4) > Hence, the patch for this one will be modified accordingly. I think we still are waiting for an updated patch, right?
Created attachment 90696 [details] final patch I've attached the revised pacth fixing the issue. It uses latest API additions to Point (i.e. preciseX(), preciseY() methods. Rnady, could you please code review this fix and provide feedback? Thanks.
Do we have any concerns that the location for the RelativeBendpoint now returns a PrecisionPoint rather than a Point. (i.e. x and y are not float). I am not 100% sure we have called updateInts() when creating the PrecisionPoint.
PrecisionPoint(double, double) calls updateInts(), so we should be good in terms of integer values for Point.
ok then, committed to HEAD
