Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 168794

Summary: ScaledGraphics needs to be more accurate in zooming clip/fill
Product: [Tools] GEF Reporter: Chris Lee <eclipse>
Component: GEF-Legacy Draw2dAssignee: gef-inbox <gef-inbox>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: P3    
Version: 3.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
patch for the Shapes example to demonstrate the bug
none
shapes example demonstrating the bug none

Description Chris Lee CLA 2006-12-20 18:33:25 EST
Build ID: M20060629-1905

Steps To Reproduce:
1. Apply the attached patch to the shapes example (it sets the zoom level to be 1/15, stops the shape outline from being drawn on rectangles, and makes shapes set themselves in different colors for contrast)
2. Open the attached shape example
3. Examine where the two rectangles touch (use the Windows Accessibility magnifier if necessary).
4. Note that even though the properties are set on the objects so they shouldn't overlap, it looks like they do.  ScaledGraphics should be more accurate in the rendering so that figures that do not intersect aren't drawn like they intersect.


More information:
We originally found this problem in our product; our model coordinate system is very exact (1/1440 of an inch), so we have a UI multiplier of 15 set so that it renders properly at 96dpi.

I've traced the problem to be related to the various zoomXXX methods in ScaledGraphics that convert from model coordinates to view coordinates.  

In this example, the top shape is translated from (x,y,w,h) of 
(2000, 0, 2400, 201) to (133, 0, 161, 14); 
the bottom is translated from 
(2100, 203, 1350, 540) to (140, 13, 90, 37).

Note that although the models do not overlap at all, ScaledGraphics zooms & renders the rectangles such that they overlap.

Ideally, this should still be accurate even if the y-position of Rectangle #2 is changed from 203 to 201 (it should become flush with Rectangle #1, but NOT overlap).
Comment 1 Chris Lee CLA 2006-12-20 18:34:31 EST
Created attachment 56008 [details]
patch for the Shapes example to demonstrate the bug

attached patch to Shapes example to demonstrate the bug
Comment 2 Chris Lee CLA 2006-12-20 18:35:57 EST
Created attachment 56009 [details]
shapes example demonstrating the bug

attached shapes example file to open with the patched Shapes example & demonstrate the bug
Comment 3 Chris Lee CLA 2007-03-14 13:45:29 EDT
Rendering fidelity is a very important issue for us - is there any chance of at least someone looking at this bug?  Is this a known issue?
Comment 4 Randy Hudson CLA 2007-03-14 14:27:23 EDT
This behavior is working as designed. If you want different scaling, you need to use fillPolygon() instead of fillRectangle().
Comment 5 Anthony Hunter CLA 2007-03-21 08:05:03 EDT
(In reply to comment #4)
> This behavior is working as designed. If you want different scaling, you need
> to use fillPolygon() instead of fillRectangle().