[OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code
james.graham at oracle.com
Tue Aug 10 20:00:15 UTC 2010
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
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
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.
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
>> 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?
More information about the 2d-dev