Community
Participate
Working Groups
The optimize clip feature messes up border items in GMF. Wonder if we can just return figure bounds instead without intersecting them again with the parent's client area. Parent's client area under normal circumstances should be the parent's client area anyway. Alexander, would you be ok removing the optimize clip case in Figure#paintChildren(Graphics)? It just wasn't there initially in the Figure#paintChildren(Graphics), hence not having it there is potentially less risky.
Yes. I think this should be ok, as paintClientArea() already sets a respective clipping rectangle on the graphics before passing it into paintChildren() this would not have to be done here again. I also agree that it would make it safer to not run into any further regressions, as the code would then pretty much be the same as prior to 3.6 in case no clipping strategy is set. I would then propose to change it into the following: protected void paintChildren(Graphics graphics) { for (int i = 0; i < children.size(); i++) { IFigure child = (IFigure) children.get(i); if (child.isVisible()) { // determine clipping areas for child Rectangle[] clipping = null; if (clippingStrategy != null) { clipping = clippingStrategy.getClip(child); } else { // default clipping behavior is to clip at bounds clipping = new Rectangle[] { child.getBounds() }; } // child may now paint inside the clipping areas for (int j = 0; j < clipping.length; j++) { if (clipping[j].intersects(graphics .getClip(Rectangle.SINGLETON))) { graphics.clipRect(clipping[j]); child.paint(graphics); graphics.restoreState(); } } } } }
Great! Thank you, Alexander - the proposed fix looks good to me!
Anthony, are we good to go for RC2 with this?
Alex or Alexander, Can you create a patch for this and commit to CVS? I can then run RC2 today.
I'll do it
Created attachment 169849 [details] patch The patch we agreed on
Delivered for 3.6 RC2
