Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 315900 - Fix clipping related problems (with GEF/Draw2D 3.6)
Summary: Fix clipping related problems (with GEF/Draw2D 3.6)
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Gef3d (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-06 06:44 EDT by Jens Von Pilgrim CLA
Modified: 2021-03-23 18:16 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Von Pilgrim CLA 2010-06-06 06:44:27 EDT
As of GEF version 3.6, the paint algorithm has been slightly modified. That is, a IClippingStrategy is used in order to paint only children within the current clipping area. Unfortunately, Draw3D is a little bit sloppy with clipping areas. I have already fixed a problem related to that issue in FreeformLayer3D (see #initSize()), however I have observed rendering bugs which only occur with GEF 3.6 (the very same code works with 3.5). E.g., only some or even no selection handles (these little cubes) become visible. I can only assume that this is related to the new clipping strategy as well (since this seems to be the only major change in GEF/Draw2D 3.6).
Comment 1 Jens Von Pilgrim CLA 2011-04-02 10:31:40 EDT
Fixed with a dirty workaround in rev. 561.

the update from Draw2D 3.5 to 3.6 introduces a new feature in Figure: a clipping strategy. With this new strategy, the paintChildren method has been slightly changed, which causes problems with GEF3D: in some cases, no figures are painted anymore.

I have analyzed the problem and it can be reduced to a change of behavior in paintChildren(..), which may also effects pure 2D implementations:

In version 3.5, in Figure.paintChildren(Graphics) the following (slightly simplfied) condition is checked to decide whether a child is to be drawn or not:

if (child.intersects(graphics.getClip(Rectangle.SINGLETON)))

In version 3.6, the rectangles of the clipping strategy are tested. If no clipping strategy is provided, the clipping rectangle used in 3.6 usually is simply the bound of the child. Simplified, that means the following condition is checked:

if (child.getBounds().intersects(graphics.getClip(Rectangle.SINGLETON)))

Unfortunately, this is a change of the behavior:

    child.intersects(..) vs. child.getBounds().intersects(..)

In GEF3D, Figure3D.intersects(..) is overridden and always returns true. We changed that, since redrawing is differently handled in Draw3D, as in case of a redraw, the whole 3D scene has to be redrawn, and there are no dirty areas.

I have added a  workaround in Draw3D rev. 561 which returns a special rectangle in Figure3D.getBounds():

public Rectangle getBounds() {
    return new Rectangle(super.getBounds()) {
        ..
        @Override
        public boolean intersects(Rectangle i_rect) {
            return true;
        }
    };
}

I'm well aware that this is a dirty dirty workaround, as is the whole handling of clipping and dirty regions in GEF3D/Draw3D. Volunteers refactoring that issues are welcome!