[OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code

[Jim Graham]

Hi Denis,

WRT the difference in the strokepath - as long as it fills correctly 
then I don't think it is out of spec as we only specify that BasicStroke 
returns a path that fills the appropriate pixels.  Is their fill area 
correct?

But, it would be a nice thing to have some consistency, and it begs the 
question - is there some error that this alternate stroking technique 
might introduce that we just haven't found yet?  For instance, is it 
robust with respect to winding rules if you overlay 2 such stroked 
objects?  Also, it looks like a simple error in choosing which pairs of 
points to connect when rounding a bend (probably back to the initial 
moveto?).

Clipping geometry outside of a clip is a topic for another discussion. 
One issue to keep in mind is that floating point clipping equations can 
sometimes return numbers that are N.49999 or N.50000 or N.50001 and that 
subtle difference may not matter for AA, but it can cause a pixel to 
appear or disappear under non-AA rendering which would be bad if it 
happens when the scene is already rendered and then you have to update a 
small clipped part of it for some repaint() call and the rendering turns 
out different during that update due to the clipping math...  8-|  So, I 
typically only cull/clip items when I am down to the bottom level and I 
can directly know how the equations are going to relate to the final 
numbers that are used to choose pixels.

			...jim

On 8/10/2010 6:42 AM, Denis Lila wrote:
> Hi Jim.
>
>> What was the problem - I might have a guess as to the cause if I saw a
>> picture.  You should file a bug against it to make sure it doesn't fall
>> through the cracks.
>      I can confirm that none of my changes introduced the bug. I just tested it
> with a truly fresh build of openjdk7. I've attached 3 screenshots with
> results.
>
>> But, these 3 are really getting down to the nitty gritty.  I'd check it
>> in before I drive you crazy... ;-)
>      Good idea :)
>      I'll keep the 3 comments in mind for future work. I actually already
> implemented something like your third suggestion, but it was along with
> some other changes and I introduced a bug, so I discarded it because I
> didn't want to spend too much time debugging.
>      Speaking of which, wouldn't it be a good idea to clip lines (perhaps
> earlier than Renderer, so that Stroker, Dasher, and Renderer can benefit
> from it)? We could only do this for lines that are out of bounds vertically,
> otherwise anti aliasing would break, but for lines that are out of bounds
> horizontally we could collapse their x coordinate to boundsMinX-1 or boundsMaxX+1
> (or bounds +/- lineWidth, if we're doing it before Renderer.java).
> That would at least reduce their length, and I can't see how it might break
> anti aliasing.
>      Am I missing anything? Or would this simply not be worth the added processing?
>
> Thanks,
> Denis.