[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code
From:       dlila () redhat ! com (Denis Lila)
Date:       2010-08-10 20:59:14
Message-ID: 127463181.2118701281473954797.JavaMail.root () zmail04 ! collab ! prod ! int ! phx2 ! redhat ! com
[Download RAW message or body]

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.graham at 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.

[prev in list] [next in list] [prev in thread] [next in thread]