Hello Jim.
> 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?
Ah. That's why I said I wasn't sure this was a bug. If that's what the
spec says, then it's not a bug, because the fill areas are the same.
> 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?).
I was thinking the "problem" was that instead of going to the position of the
last moveTo, we were going to the position of the last moveTo + Offset.
That would explain the difference in the top left, but not the bottom right.
I will have to look at Stroker some more.
Regards,
Denis.
----- "Jim Graham" <james.gra...@oracle.com> wrote:
> Hi Denis,
>
> 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.
