< prev index next >

test/java/awt/Graphics/LineClipTest.java

Print this page
rev 14836 : 8159690: [TESTBUG] Mark headful tests with @key headful.
   1 /*
   2  * Copyright (c) 2002, 2013, Oracle and/or its affiliates. All rights reserved.
   3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   4  *
   5  * This code is free software; you can redistribute it and/or modify it
   6  * under the terms of the GNU General Public License version 2 only, as
   7  * published by the Free Software Foundation.
   8  *
   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 
  24 /**
  25  * @test

  26  * @bug   4780022 4862193 7179526
  27  * @summary  Tests that clipped lines are drawn over the same pixels
  28  * as unclipped lines (within the clip bounds)
  29  * @run main/timeout=600/othervm -Dsun.java2d.ddforcevram=true LineClipTest
  30  * @run main/timeout=600/othervm LineClipTest
  31  */
  32 
  33 
  34 /**
  35  * This app tests whether we are drawing clipped lines the same
  36  * as unclipped lines.  The problem occurred when we started
  37  * clipping d3d lines using simple integer clipping, which did not
  38  * account for sub-pixel precision and ended up drawing very different
  39  * pixels than the same line drawn unclipped.  A supposed fix
  40  * to that problem used floating-point clipping instead, but there
  41  * was some problem with very limited precision inside of d3d
  42  * (presumably in hardware) that caused some variation in pixels.
  43  * We decided that whatever the fix was, we needed a serious
  44  * line check test to make sure that all kinds of different
  45  * lines would be drawn exactly the same inside the clip area,


   1 /*
   2  * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved.
   3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   4  *
   5  * This code is free software; you can redistribute it and/or modify it
   6  * under the terms of the GNU General Public License version 2 only, as
   7  * published by the Free Software Foundation.
   8  *
   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 
  24 /**
  25  * @test
  26  * @key headful
  27  * @bug   4780022 4862193 7179526
  28  * @summary  Tests that clipped lines are drawn over the same pixels
  29  * as unclipped lines (within the clip bounds)
  30  * @run main/timeout=600/othervm -Dsun.java2d.ddforcevram=true LineClipTest
  31  * @run main/timeout=600/othervm LineClipTest
  32  */
  33 
  34 
  35 /**
  36  * This app tests whether we are drawing clipped lines the same
  37  * as unclipped lines.  The problem occurred when we started
  38  * clipping d3d lines using simple integer clipping, which did not
  39  * account for sub-pixel precision and ended up drawing very different
  40  * pixels than the same line drawn unclipped.  A supposed fix
  41  * to that problem used floating-point clipping instead, but there
  42  * was some problem with very limited precision inside of d3d
  43  * (presumably in hardware) that caused some variation in pixels.
  44  * We decided that whatever the fix was, we needed a serious
  45  * line check test to make sure that all kinds of different
  46  * lines would be drawn exactly the same inside the clip area,


< prev index next >