The fix to 4693161 (clipped line performance) introduced a regression in line quality.

Basically, we now perform line clipping in integer coordinates at too high a level. This lack of precision causes a difference between how we render clipped
versus unclipped lines.

Here's a beautiful ASCII representation of what is happening:

Supposed we have a line that spans 10 pixels in the x direction and 1 in the
y direction:

-----
     -----

Most line-drawing algorithms would step down one pixel at the half-way point.

Now, suppose we have a user clip at x=2. The result should be a line that
begins 2 pixels over from the previous line, but is otherwise identical:

  ---
     -----

What we actually get through our newly clipped d3d lines is the following:

  ----
      ----

So we now drop down one in y one pixel over from where we did prior to clipping our d3d lines.

I've attached a simple app that shows the problem clearly. Run it on the latest
jdk1.4.2 (b7 or later) and note the following:
- The Blue line is painted first. The Black line represents the Clip
boundary. The red line is painted over the blue line.
- If the bug does not exist, you should see the blue line to the left of
the black line and the red line to the right of the black line (completely
hiding the blue line).
- When the bug is present, you will see the blue line, the red line, and
also more blue about halfway across the red line. This extra blue is the error
introduced in the new clipping algorithm.
- For a cooler, flashier version of the app run "java LineClipError -dynamic",
which scrolls the clip to the left and right; observe that the error (the amount of blue that shouldn't be there) increases and decreases with the position of the clip.