Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4212743

Provide antialiased (i.e. soft edged) clipping

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P5
    • Resolution: Unresolved
    • Affects Version/s: 1.2.0, 1.4.0
    • Fix Version/s: None
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
      2d
    • Understanding:
      Fix Understood
    • CPU:
      generic, x86
    • OS:
      generic, windows_nt

      Description



      Name: gsC80088 Date: 02/18/99


      When an image or filled shape is clipped, it isn't antialiased along the clipping path. Here's a sample program illustrating the problem -- it draws a filled rectangle, clipped by an ellipse.

      import java.awt.*;
      import java.awt.geom.*;

      public class Clipper extends Canvas {

        public static void main(String args[]) {
          Canvas canvas = new Clipper();
          Frame frame = new Frame();
          frame.setSize(640, 480);
          frame.add("Center", canvas);
          frame.show();
        }

        public void paint(Graphics g) {
          Graphics2D g2d = (Graphics2D) g;
          g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
          g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
          g2d.setColor(Color.red);
          g2d.clip(new Ellipse2D.Float(100, 100, 300, 200));
          g2d.fillRect(100, 100, 300, 200);
        }
      }
      (Review ID: 54362)
      ======================================================================

        Issue Links

          Activity

          Hide
          flar Jim Graham added a comment -
          BT2:EVALUATION

          This is by design. Clip shapes are not antialiased since the accumulated
          blending operations along their outline would erode those pixels until
          none of the original color remained, thus defeating the purpose of
          antialiasing the edge in the first place.

          Clipping actions should, in general, be reproducible so that if you
          render with two non-overlapping clip shapes, you can perform the
          operations in either order and achieve the same effect. Antialiased
          clipping violates this rule since the edge operations would depend
          on the order in which the immediate mode operations were performed.

          If you want a rendering to be composited on top of another with blended
          edges then the best way to achieve that effect would be to render the
          drawing to a BufferedImage and then blend that image onto the destination
          in one of two ways.

          1. Install the BufferedImage as a Texture and perform an
          antialiased fill of the desired shape.

          2. Use a BufferedImage with a full alpha channel and then
          render the desired shape antialiased onto the BufferedImage
          with an AlphaComposite.DST_IN operation. Finally, composite
          the drawing onto the destination with an AlphaComposite.SRC_OVER
          operation.

          It also bears mentioning that hints are just hints and can be ignored by
          any compliant implementation so this is not a bug even if antialiased
          clipping were feasible or desireable.

          I will change this to an RFE since there are at least 2 ways in which it
          might be useful:

          1. The developer may acknowledge that edge operations accumulate
          errors and still want the effect regardless, most likely for
          single operations which only perform a single edge operation
          and don't have time to accumulate any errors over multiple
          operations. Developers would have to use the capability with
          those caveats in mind though.

          2. We could, with a great deal of effort, employ a sub-pixel
          mask record for each pixel to calculate the edge effects more
          exactly and remember the history of colors and coverages for
          each pixel as we proceed. This mechanism would enable us
          to do much more intuitively accurate soft clipping, but we
          have no plans to ever enhance the implementation in this way.

          In either case, the capability would be controlled through a separate
          hint since the default case has behavior implications that would create
          incorrect results if care was not taken to minimize the operations.

          jim.graham@Eng 1999-02-19
          Show
          flar Jim Graham added a comment - BT2:EVALUATION This is by design. Clip shapes are not antialiased since the accumulated blending operations along their outline would erode those pixels until none of the original color remained, thus defeating the purpose of antialiasing the edge in the first place. Clipping actions should, in general, be reproducible so that if you render with two non-overlapping clip shapes, you can perform the operations in either order and achieve the same effect. Antialiased clipping violates this rule since the edge operations would depend on the order in which the immediate mode operations were performed. If you want a rendering to be composited on top of another with blended edges then the best way to achieve that effect would be to render the drawing to a BufferedImage and then blend that image onto the destination in one of two ways. 1. Install the BufferedImage as a Texture and perform an antialiased fill of the desired shape. 2. Use a BufferedImage with a full alpha channel and then render the desired shape antialiased onto the BufferedImage with an AlphaComposite.DST_IN operation. Finally, composite the drawing onto the destination with an AlphaComposite.SRC_OVER operation. It also bears mentioning that hints are just hints and can be ignored by any compliant implementation so this is not a bug even if antialiased clipping were feasible or desireable. I will change this to an RFE since there are at least 2 ways in which it might be useful: 1. The developer may acknowledge that edge operations accumulate errors and still want the effect regardless, most likely for single operations which only perform a single edge operation and don't have time to accumulate any errors over multiple operations. Developers would have to use the capability with those caveats in mind though. 2. We could, with a great deal of effort, employ a sub-pixel mask record for each pixel to calculate the edge effects more exactly and remember the history of colors and coverages for each pixel as we proceed. This mechanism would enable us to do much more intuitively accurate soft clipping, but we have no plans to ever enhance the implementation in this way. In either case, the capability would be controlled through a separate hint since the default case has behavior implications that would create incorrect results if care was not taken to minimize the operations. jim.graham@Eng 1999-02-19

            People

            • Assignee:
              flar Jim Graham
              Reporter:
              gstone Greg Stone
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Imported:
                Indexed: