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.
