t;>>>>> didn't
> >>>>>>>> implement it because I thought the point was to get rid of
> the
> >>>>>>> sampling
> >>>>>>>> at this stage. However, if performance is the issue, then I
> >>>> guess
> >>
uick way of computing, for each scan line, all its
intersections
with
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I
am
not
very
familiar with Bezier curves, but it doesn't seem easy enough
to
justify
fixing such a small
how it does this).
In order to implement Bezier curves in Renderer, we would have
to
have
a quick way of computing, for each scan line, all its
intersections
with
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I
am
not
very
famil
es in Renderer, we would have
to
have
a quick way of computing, for each scan line, all its
intersections
with
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I
am
not
very
familiar with Bezier curves, but it doesn't seem ea
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I
am
not
very
familiar with Bezier curves, but it doesn't seem easy enough
to
justify
fixing such a small bug.
- Original Message -
From: "Jim Graham"
To
ions
> >>>>> than the round-cap code since it would have to be written for
> >>>>> arbitrary
> >>>>> beziers whereas if you know it is a quarter circle then it is
> >>> easier
> >>>>> to
> >>>>> know how far to su
> >>>>>> bezier.
> >>>>>>
> >>>>>> So, perhaps it would be worth having it check the type of the
> >>>> output
> >>>>>> and
> >>>>>> do either a bezier or a bunch of lines depending on if i
, for each scan line, all its
intersections
with
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I am
not
very
familiar with Bezier curves, but it doesn't seem easy enough to
justify
fixing such a small bug.
- Original Message
familiar with Bezier curves, but it doesn't seem easy enough to
justify
fixing such a small bug.
- Original Message -
From: "Jim Graham"
To: "Denis Lila"
Cc: 2d-dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
Eastern
Subj
one, as I am
not
very
familiar with Bezier curves, but it doesn't seem easy enough to
justify
fixing such a small bug.
----- Original Message -
From: "Jim Graham"
To: "Denis Lila"
Cc: 2d-dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US
;> 1. As an implementation of BasicStroke's createStrokedShape
> > method.
> > >> This
> > >>> uses a Path2D object as output.
> > >>> 2. As a way of feeding a PathConsumer2D without calling
> > >> createStrokedShape
> >
how this could be done, as I am
not
very
familiar with Bezier curves, but it doesn't seem easy enough to
justify
fixing such a small bug.
- Original Message -----
From: "Jim Graham"
To: "Denis Lila"
Cc: 2d-dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:
with
however many Bezier curves are being drawn.
I haven't given much thought to how this could be done, as I am
not
very
familiar with Bezier curves, but it doesn't seem easy enough to
justify
fixing such a small bug.
----- Original Message -
From: "Jim Graham"
To:
> >> Renderer.
> >>> 1 and 2 aren't problems, because the underlying output objects
> >> support
> >>> Bezier curves. 3, however, doesn't, and it seems like implementing
> a
> >>> curveTo method for Renderer would be very difficult bec
ses a PathConsumer2D
> > >> output.
> > >>> 3. As a way of feeding lines to a Renderer object, which
> > generates
> > >> alpha
> > >>> tiles used for anti-aliasing that are fed to a cache and
> > extracted
> > >> as needed
> &g
gt;> curveTo method for Renderer would be very difficult because the
> way
> >> it
> >>> generates alpha tiles is by scanning the drawn edges with
> >> horizontal
> >>> scan lines, and for each scan line finding the x-intersections of
> >>
Lila"
Cc: 2d-dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on
scaled lines.
I don't understand - why do we generate sample points based on the
size
of the cap? Why not generate
f computing, for each scan line, all its intersections
> with
> > however many Bezier curves are being drawn.
> >
> > I haven't given much thought to how this could be done, as I am not
> very
> > familiar with Bezier curves, but it doesn't seem easy enough to
"
Cc: 2d-dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
I don't understand - why do we generate sample points based on the size
of the cap
dev@openjdk.java.net
Sent: Wednesday, June 9, 2010 7:42:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Fix for drawing round endcaps on scaled lines.
I don't understand - why do we generate sample points based on the size
of the cap? Why not gene
I don't understand - why do we generate sample points based on the size
of the cap? Why not generate a pair of bezier quarter-circles and let
the rasterizer deal with sampling?
...jim
Denis Lila wrote:
Hello.
I think I have a fix for this bug:
http://icedtea.classpat
Hello.
I think I have a fix for this bug:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=506
Basically, the problem is that if there is a magnifying affine transformation
set on the graphics object and one tries to draw a line with small thickness
and round end caps, the end caps appear
22 matches
Mail list logo
