Resending: (the previous e-mail had a large webrev.zip attachmet. I am now
hosting the webrev on Dropbox:
http://dl.dropbox.com/u/29228818/webrev/index.html)
On Tue, Aug 23, 2011 at 4:55 PM, Denis Lila wrote:
> Hi Jim.
>
>> - I'd like to see the Renderer cache implemented in th
> That's awesome! I'll look into reviewing the changes soon...
Nice :D
Thanks,
Denis.
- Original Message -
>
> ...jim
>
> On 7/20/2011 11:05 AM, Denis Lila wrote:
> >> If we let Ductus' design constraints (which were penned over a
> >>
> It might be worth investigating how hard it would be to fix those
> dependencies so that we aren't held back with Pisces. I can't imagine
> it can be that daunting a task (unfortunately I'm heavily committed to
> another project right now, or I'd investigate it myself)
I'll try looking into this
Hi Roman.
> - What speaks against doing that? E.g. outputting pixelrow by
> pixelrow?
> I was implementing a pure Java AA scanline converter for GNU Classpath
> some years ago and this is exactly what I did. I found that useful
> because drawing horizontal lines is often very cheap (i.e. filling
>
Hi Jim.
We spoke about this a while ago and I started working
on it. This is what I have so far:
http://icedtea.classpath.org/~dlila/webrevs/RendererPerf/
My main intention was to remove some stages
from the renderer (like you suggested) because what
we were doing was:
1. Transform curves to line
was pushed under 7049339 I will swap that around,
> closing 6775390 as a dup. of 7049339.
Thank you,
Denis.
- Original Message -
>
> -phil.
>
>
> On 6/24/2011 1:52 PM, Denis Lila wrote:
> >> Hi Denis,
> >>
> >> Looks good to me!
> > Thank
> Hi Denis,
>
> Looks good to me!
Thanks Jim!
- Original Message -
>
> ...jim
>
> On 6/24/2011 10:19 AM, Denis Lila wrote:
> > Hi.
> >
> > I think this webrev:
> > http://icedtea.classpath.org/~dlila/webrevs/Bug7049339/
> > fixes 70
Hi.
I think this webrev:
http://icedtea.classpath.org/~dlila/webrevs/Bug7049339/
fixes 7049339 and I would like to commit it.
At the very least it fixes batik-squiggle printing
and the included regression test.
Any comments are appreciated.
Thank you,
Denis.
the review (and pointing out the
performance improvement, and the bug itself... :)
Regards,
Denis.
- Original Message -
> Hi Denis,
>
>
> ...jim
>
> On 4/27/2011 7:57 AM, Denis Lila wrote:
> >> Why don't you back them out and put up a webrev so I can proof it
> >> before
> >> you push. I'll get to it today...
...
t.
I also removed a comment from computeIntersection. It didn't
belong there, since that was a general intersection computing
routine, and didn't necessarily have anything to do with miters.
Regards,
Denis.
- Original Message -
>
> ...jim
>
> On 4/26/2011 2:11 PM,
quot; and put the test only in that copy
> > > (which is
> > > only used from the quad function) until I have time to do some
> > > more
> > > exhaustive performance tests. To be honest, though, I don't
> > > imagine
> > >
repo but forgot to update.
That's why I was still seeing the problem after building.
Well, the regression test is written. Do we want to push that
(once I change the names to the original bug id, of course)?
Regards,
Denis.
- Original Message -
> Denis,
>
>
> -phil.
>
t I wait for final confirmation?
- Original Message -
> Hi Denis,
>
> On 3/4/2011 3:40 PM, Denis Lila wrote:
> >> line 355: Make that "16" a constant?
> >
> > Sure.
>
>
> New stuff:
>
> Stroker.java:
>
>
>
> ...jim
x27;ll include
the regression test you gave me.
Regards,
Denis.
- Original Message -
> Hi Denis,
>
>
> ...jim
>
> On 4/26/2011 1:01 PM, Denis Lila wrote:
> >>> I'm not completely sure. Maybe to plug holes between curves after
> >>> subdivisi
infinity, and
all other x values are obvious, I think.
> You could actually avoid all of the "!" by swapping the code bodies
> around and using if/else:
>
> if (both finite) {
> quad1 code
> } else {
> computeIntersection2
> if (both finite) {
> quad2 co
a sum of squares. It can't be negative anything. Doh!
I've removed it.
Updated webrev:
http://icedtea.classpath.org/~dlila/webrevs/7036754/webrev/
Regards,
Denis.
- Original Message -
> Hi Denis,
>
>
> On 4/20/2011 6:40 AM, Denis Lila wrote:
> >> Finally
l Message -
> Hi Denis,
>
>
>
>
> Also, your suggestion below makes sense to me...
>
> ...jim
>
> On 4/19/11 11:11 AM, Denis Lila wrote:
> >
> > Jim, what do you think about completely removing this code:
> >
> > final boolean p1
style guidelines are to put a space
> between the cast and the expression - you might as well fix those
> missing spaces while you are playing with all those lines of code.
>
>
> ...jim
>
> On 4/18/11 12:05 PM, Denis Lila wrote:
> > Hi Jim.
> >
> >> Hm. It t
; > exhaustive performance tests. To be honest, though, I don't imagine
> > that
> > single test could affect performance (given that "den" is already
> > computed as the difference of two values, the subtract operation
> > already
> > sets condition codes
Hi.
Jim Graham pointed out this bug to me.
A fix is here:
http://icedtea.classpath.org/~dlila/webrevs/7036754/webrev/
It just checks for inf/nan and just emits a line joining
the endpoints in that case.
The stroking is no longer symmetric with respect to right
and left polynomial degrees. This
Hi.
This webrev has a fix for 7027667:
http://icedtea.classpath.org/~dlila/webrevs/7027667/webrev/
Although, for some reason, the diff in the webref for
AAShapePipe.java shows nothing. It should be (this is what hg diff
gives me):
diff -r 155d91257957 src/share/classes/sun/java2d/pipe/AAShapePip
> I think the code is good to go, but could you create an automated test
> case for this? It should be easy to render a simple shape to a
> rendered
> image and verify that the last scanline was touched, no?
Ok, the test is now in the webrev.
into a JTreg test.
- Original Message -
>
> ...jim
>
> On 3/10/2011 11:06 AM, Denis Lila wrote:
> > Hi Jim.
> >
> >> Yes, that was the point of my original question. I was asking how
> >> you
> >> felt about the dead code, apologies that it t
-
> Hi Denis,
>
>
> ...jim
>
> On 3/10/2011 6:38 AM, Denis Lila wrote:
> >> [Resending due to bounces...]
> >>
> >> On 3/9/2011 5:56 AM, Denis Lila wrote:
> >>>> lines 1002& 1083 - can breaking points of a cubic generate quad
> &
> [Resending due to bounces...]
>
> On 3/9/2011 5:56 AM, Denis Lila wrote:
> >> lines 1002& 1083 - can breaking points of a cubic generate quad
> >> segments and vice versa?
> >
> > No, the functions that generate the offset curves can only
> > r
I also removed the System.exit(1) calls in PiscesTileGenerator.
It doesn't seem like a good idea to shut down the whole VM
because of a rendering bug.
- Original Message -
> Hi Jim.
>
> > Forgive my ascii art shorthand, "=>" was supposed to be an arrow,
> > not
> > a
> > comparison operat
Hi Jim.
> Forgive my ascii art shorthand, "=>" was supposed to be an arrow, not
> a
> comparison operator. I was saying that you use the word "and" on that
> line and it should be changed to the word "or" because a non-compliant
> edge can be invalid by violating either (i.e. "or") condition. In
>
erer.java:
>
>
>
>
> Stroker.java:
>
>
> ...jim
>
> On 3/4/2011 1:04 PM, Denis Lila wrote:
> > Hi.
> >
> > In my last push to pisces I introduced a regression.
> > The scanline iterator doesn't iterate over the last
> > scanl
Hi.
In my last push to pisces I introduced a regression.
The scanline iterator doesn't iterate over the last
scanline. This:
http://icedtea.classpath.org/~dlila/webrevs/7019861_skipped_last_scanline/webrev/
fixes it.
The webrev also includes a workaround for a hotspot
bug and a minor optimizatio
Hi Jim,
Here's the first draft of the multithreading in pisces:
http://icedtea.classpath.org/~dlila/webrevs/MT/webrev/
There's 1-2 bugs in there somewhere. There's an OOB
in splitEdgesAtStrips which shouldn't be hard to fix,
and I saw an instance where I miss a crossing and the
whole line is fill
- Original Message -
> Odd, I searched on the bugid and didn't find it either.
>
> I then struggled with a bunch of internal network problems before I
> was
> able to confirm that it is in the system internally so I tried
> searching
> on bugs.sun.com again and still didn't find it.
>
> B
class we want exists
> and is visible to us and if not simply print a warning?
>
>
> Thank you,
> Denis.
>
> - Original Message -
>
> >
> > ...jim
> >
> > On 2/4/2011 6:02 AM, Denis Lila wrote:
> > >> Do these also pass closed JDK?
s before running
each test we could check that the implementation class we want exists
and is visible to us and if not simply print a warning?
In the meantime, I'll go ahead and push it without the tests.
Thank you,
Denis.
- Original Message -
>
> ...jim
>
> On 2/4/2011
> Do these also pass closed JDK? So far I don't know of any way to
> identify a test as "Open Rasterizer only"...
I don't think so. When I run it with closed source java it
complains about no PathConsumer2D.
- Original Message -
>
> ...jim
>
>
/12df222ab029/patches/rendering-engine-tests.patch
One of them doesn't have a sun bugid, so we should probably just skip it.
I'm not sure how we would include them, since they all test bugs that
have already been fixed.
Regards,
Denis.
- Original Message -
> Thanks Denis,
>
d the calculation of slope up above
> here
> and just used the sign of the slope as the test for x ordering. Note
> that if the slope calculations immediately precedes the "if (slope <
> 0)"
> test then the condition codes are likely already set as a side effect
> of
>
Ah, I'm sorry. I forgot to CC the list.
- Forwarded Message -
From: "Denis Lila"
To: "Jim Graham"
Sent: Tuesday, February 1, 2011 6:04:09 PM
Subject: Re: [OpenJDK 2D-Dev] CubicCurve2D.solveCubic and
containment/intersection bugs.
Hi Jim.
The webrev for the p
tested it myself
with a build without my fixes. I attached a regression test.
Regards,
Denis.
- Original Message -
> On 1/27/2011 2:03 PM, Denis Lila wrote:
> >> When I first saw "I am Denis Lila" I chuckled because it came
> >> across like "I am Iro
> When I first saw "I am Denis Lila" I chuckled because it came
> across like "I am Ironman"
:-D
Well, it is pushed. Now all that's left on my end is the performance
improvement for pisces (dashing in particular). Could you please file
a performance regression bug
effort and might be
> eliminated if we ever change to a new revision system.)
Done.
> Oh, and I just looked at the tests now and they look good too...
Is it good to go now?
Thank you,
Denis.
- Original Message -
> Whoops, one last optimization:
>
>
> One last suggesti
capping the error for larger
> polynomials introduce the same root count errors for them?
I did some testing and it turns out that the caps are not needed. I have
removed them.
> 1105 should now use P,Q instead of p,q right?
Yeah, you're right.
I also added a lot of comments.
Than
?
Good point.
> Line 1179 - isn't that already done in getRUB()? (And see my comment
> about eliminating the "max()")
Yeah. This is a leftover from when I used to compute RUB inline.
The URL is the same:
http://icedtea.classpath.org/~dlila/webrevs/cc2d/webrev/
Regards,
De
> in awt.Shape or whether it meant the same thing as in topology. They
> may
> actually be equivalent in the case of intersects() (but even so, we
> should
> be consistent with our wording),
>
> Regards,
> Denis.
>
> - Original Message -
> > Hi Denis,
d that you sent a while
ago, but I'm not a big fan of regression tests that have a small chance of
failing even when nothing is wrong. What do you think about this?
Regards,
Denis.
- Original Message -
>
> ...jim
>
> On 1/21/2011 1:00 PM, Denis Lila wrote:
> >>
ains(), where we also use the word "interior".
Regards,
Denis.
- Original Message -
> Hi Denis,
>
> On 1/24/2011 3:41 PM, Denis Lila wrote:
> >> Perhaps the problem is less with the word "boundary" than it
> >> is with confusing our use of t
last push) and send it.
Regards,
Denis.
- Original Message -
>
> ...jim
>
> On 1/21/2011 1:00 PM, Denis Lila wrote:
> >> I think so, but Phil knows more about the scripts that verify a
> >> push.
> >>
> >> I think they do look for the bugi
that a set has an interior in addition to (and mostly separate from)
> its boundary?
That was exactly the problem. We classify every point as either inside
or outside, and I'm used to the interior, exterior, and boundary being
disjoint.
Regards,
Denis.
- Original Message -
> H
nges.
Thank you,
Denis.
- Original Message -
>
> ...jim
>
> On 1/19/11 10:57 AM, Denis Lila wrote:
> >> In general, if you can, you should write a short regression test
> >> and
> >> push it with your checkin. I probably should have mentioned that
&g
> In general, if you can, you should write a short regression test and
> push it with your checkin. I probably should have mentioned that
> before
> you pushed since these bugs sound like they are conducive to a tiny
> automatic regression test.
Sorry about that.
> At this point we'd need a new b
oint
> > of
> > those two quarters is inside the rectangle and return
> > RECT_INTERSECTS.
> >
> > So the version that orders the recursive calls gets away with 2
> > subdivisions, while the original version must do 3-5.
> >
> > But I'm not sure
;
> ...jim
>
> On 1/13/11 9:50 AM, Denis Lila wrote:
> > Hi Jim.
> >
> >> One general comment about the new helper method. I probably
> >> wouldn't
> >> bother loading the control points into local variables since you
> >> only
> >
e (from my previous e-mail)
about 15% slower.
Regards,
Denis.
- Original Message -
> Hi Denis,
>
> On 1/12/2011 2:33 PM, Denis Lila wrote:
> > Hi Jim.
> >
> >> I replaced that test with
> >>
> >> if (!getBounds2D().contains(x, y, w, h)) {
&
Hi Jim.
> One general comment about the new helper method. I probably wouldn't
> bother loading the control points into local variables since you only
> use them once in the function. It might be wasted effort if the cubic
> function isn't called, and meanwhile you are forcing the compiler to
>
d. Almost too good, which is why I've attached the file
with the tests.
I have yet to think about the optimizations, so I'll send an e-mail later
about those.
Regards,
Denis.
- Original Message -
> Hi Denis,
>
> On 1/12/2011 2:33 PM, Denis Lila wrote:
> > Hi
Hi Jim.
> I replaced that test with
>
> if (!getBounds2D().contains(x, y, w, h)) {
> return false;
> }
>
> and that fixed both the bug and the performance of (1) without making
> (3) worse.
It turns out that that test actually slows it down a bit. It was helping
us when we were using the PathIt
Hi Jim.
> I'm all in favor of simplification by using the new crossings code. I
> originally balked at using it because I thought it might be slower,
> but I didn't do any benchmarks to back that up. Have you benchmarked
> the changes at all?
As of now, yes. I tested 3 cases: (1) when the rectang
ses a very fast general intersection
> facility in the sun.awt.geom package that is based on the above rules.
> The containment methods of all of the various shapes could be switched
> over to this mechanism except that the may have faster ways of finding
> the answer in some cases. Certain
Hi Jim.
> so it's behaving correctly (at least in this case)
However, contains(Rectangle2D) was still broken, because it
made the assumption that the line joining the endpoints splits
the cubic curve into two convex curves. This is not true - I've
attached a picture that illustrates why not (the
Hi Jim.
I'm starting a new thread about this, since "X11 uniform scaled
wide lines and dashed lines; STROKE_CONTROL in Pisces" has
absolutely nothing to do with what we were discussing :-)
> You might want to submit it as a separate push and get credit for fixing
> 4645692 (solveCubic doesn't ret
anscendental results
> will be much less accurate.
>
> Finally, this lacks the "refine them anyway if any of them are near 0
> or
> 1" rule - the original only did that if the transcendentals were used,
> but it would be nice to do that for any of the cases. It might m
Hi Jim.
> If you want to include these rendering tests as extra verification
> along with your other changes, then that is fine.
Ok, thanks. So, I'll update the performance webrev to include them.
> Also, I think we might have a script that forceably checks the value
> of the @bug tag and ensure
Hi Jim.
> What about logic like this:
>
> boolean checkRoots = false;
> if (D < 0) {
> // 3 solution form is possible, so use it
> checkRoots = (D > -TINY); // Check them if we were borderline
> // compute 3 roots as before
> } else {
> double u = ...;
> double v = ...;
> res[0] = u+v; // should
Hi Jim.
> The test as it is has a test case (I just chose random numbers to
> check
> and got lucky - d'oh!) that generates 1 solution from the new code
> even
> though the equation had 2 distinct solutions that weren't even near
> each
> other...
I figured out why this happens. It's because of c
Hi Jim.
> Unfortunately, this means that the names here
> and the values assigned to them and the comment above them conflict.
> If the variables could be named "p/3" and "q/2" then all would be clear,
> but I don't know how to do that naming very easily. Perhaps the
> comment could be simply rewo
Hi Jim.
> Lines 1094-1096, they could also be NaN if any of the numerators were
> also zero and these tests might fail (but only for the case of all of
> them being zero I guess, otherwise one of the other divisions would
> result in infinity). Are accidental infinities (caused by overflow
> rathe
Hi Jim.
> Also, I wrote new hit testing code in jdk6 that used bezier recursion
> to compute the values and it ran way faster than any root-finding methods
> (mainly because all you have to worry about is subdividing enough that
> the curve can be classified as above, below, or to the left or righ
Hi Jim.
> How big are these errors expressed as multiples of the ULP of the
> coefficients? Obviously 1e-17 is a lot smaller than 1e-4, but was
> 1e-17
> representing "just a couple of bits of error" or was it still way off
> with respect to the numbers being used? And were these fairly obscure
Hi Jim.
> You might want to submit it as a separate push and get credit for
> fixing 4645692 (solveCubic doesn't return all answers),
Sure, that sounds good. Reading through the code I found, I spotted
a few things that might have been problematic in some extremely
rare cases. I've been working o
Hello.
Please don't review these yet. I'm making some modifications
to make them much more robust. We should have a new version of
the tests in maybe one hour (at most).
Regards,
Denis.
> Very nice! How does it compare to CubicCurve.solveCubic() (which I
> know
> has issues with the 2 root case, but I got it from a "reliable source"
> -
> some textbook on Numerical Recipes)?
I wrote a tests that generated 2559960 polynomials, and in 2493075 of
those, the computed roots were i
Hi again.
I found an implementation of a closed form cubic root solver
(from graphics gems):
http://read.pudn.com/downloads21/sourcecode/graph/71499/gems/Roots3And4.c__.htm
I did some micro benchmarks, and it's about 25% slower than the one I have.
I'm thinking we should use it anyway because it'
Hi Jim.
> With respect to finding a cubic root, currently you are doing that in
> 2 dimensions, but what if we converted to 1 dimension?
> Consider that the control polygon is "fairly linear". What if we
> rotated our perspective so that it was horizontal and then squashed it
> flat? Consider i
Hi Jim.
> Woohoo!
:)
> >> How often do we end up needing getTCloseTo in practice?
> >
> > It depends on the ratios of the lengths of the sides of the control
> > polygon. The closer they are to 1, the less we need it. I'm not
> sure
> > how to answer more precisely - for that I would need a
> re
> Of course, all this is useless
> if I've done something to make things look horrible, so I'm going to
> run the gfx tests again.
I just ran them. All is good. The only change compared to the old test
result is that the number of dashed round rectangles that are identical
to what is produced by t
ote:
>
> ...jim
>
> On 12/8/2010 1:54 PM, Denis Lila wrote:
> > Hi Jim.
> >
> >>> How about "if the 3 segments of the control polygon are all close
> to
> >>> each other in length and angle", then the optimization
Hi Jim.
> Actually, even if the lengths aren't close the lengths may give you
> enough information about the acceleration along the curve that you can
> do a decent approximation of the accelerated T value. The T could be
> biased by some formula that is weighted by the ratios of the control
>
Hi Jim.
> > How about "if the 3 segments of the control polygon are all close to
> > each other in length and angle", then the optimization applies. Is
> > that easy to test?
>
> Hmm, that would actually be extremely easy to test and it would cost
> almost nothing. We already compute the control
> I'm not sure how the closed interval is awkward. Isn't it just proper
> choice of ">= and <= vs. > and <" in the testing method?
In the filtering function, yes, but I was referring to cubicRootsInAB in
Helpers:122-133 where we iterate through intervals. For each interval,
we have the values of
Hi Jim.
> The main problem is that "must" doesn't exist for IEEE floating point
> numbers. You can find the root for one of the endpoints and it may
> return "t = -.1" even though the value exactly matched the
> endpoint, but after all the math was said and done the answer
> it came up had t
onsumer
is now called only with outat, which cannot be a translation. So we may want
to remove it.
I also fixed the filterOutNotInAB function. It was violating cubicRootsInAB's
spec by filtering out everything not in (A, B), as opposed to everything not
in [A, B), which is what it sho
mplemented this (though, I haven't had
time to test it yet. That's for tomorrow).
The link is: http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/
Thank you,
Denis.
- "Jim Graham" wrote:
>
> ...jim
>
> On 12/1/2010 9:19 AM, Denis Lila
Hi Jim.
About two weeks or so ago I replied to one of your very old e-mails
about dashing performance and I included a link to the webrev:
http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/
I suspect you might have missed it, so that's why I'm writing this.
If you haven't, I apologize
length SUBPIXEL_Y_POSITIONS.
This replaces the sum variable. From here. So, if a crossing is on scanline i of
the current pixel row, then sum[i] is used. Everything else is the same.
Regards,
Denis.
- "Denis Lila" wrote:
> Hi Jim.
>
> I have a new webrev:
> http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/
>
Hi Jim.
I have a new webrev:
http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/
> How about looking more at the stroking end of the process and I'll dig
> a little more into optimal rasterization code. I have a lot of
> experience with optimizing rasterizer code (and JNI if it comes
he version where we qsorted everything. The
benchmark report says the overall performance has stayed the same because
every test other than horizontal lines is performing better by about 2-6%.
Regards,
Denis.
- "Jim Graham" wrote:
> I ended up going with:
>
>
ccumulation of numerical inaccuracies,
and I don't think we do enough iterations for this to start causing
perceptible problems. I haven't noticed anything in all my testing.
Regards,
Denis.
- "Jim Graham" wrote:
> Hi Denis,
>
> On 11/9/2010 3:06 PM, Denis Lila
nyway. This isn't
as fast as using the bounding boxes, but it's close and much more accurate.
Regards,
Denis.
- "Denis Lila" wrote:
> Hi Jim.
>
> > All lines generated from a given "allegedly monotonic" curve are
> > recorded with the same
ld handle these 4 variables?
Thank you,
Denis.
- "Jim Graham" wrote:
> Hi Denis,
>
> On 11/8/2010 2:39 PM, Denis Lila wrote:
> >> Finally, I discovered (while testing for other problems) that the
> >> curves are not truly monotonic after slicing them. I r
ensive as well...
>
> ...jim
>
> On 11/8/2010 3:23 PM, Denis Lila wrote:
> > Hi Jim.
> >
> > I like the new Renderer, but I have a question about
> edgeBucketCount.
> >
> > As far as I can see it is only used so that we can tell w
ve your version
>
> of emitRow into the Cache object. I'd send you the new code for my
> AlphaConsumer, but it is incompatible with what you need to cache so
> it
> won't help you.
>
> You'll also need a bit of un-translation cleanup as we have mirrors of
>
> all o
Hi Jim.
> A couple of questions about the code that I haven't touched...
> Is there some reason why the AFD for cubics doesn't have any tests for
> dddxy (the "constants" for its equations), but the AFD for quads is
> testing the ddxy on every loop? I know that these values do change
> when the
Hi Clemens.
> I've only followed your discussion with Jim but skipped all the
> in-depth discussion.
> From my prior experiences usually JNI is not woth the trouble, if
> you don't have a serious reason why using native code would have
> advantages (like the possibility of using SIMD or when valu
Hi Jim.
> Also, I've gotten another 20% improvement out of the design with a few
> more tweaks. (Though I measured the 20% in the stripped down version
> that I'm prototyping with FX so I'm not sure how much of that 20%
> would show up through the layers of the 2D code. Overall, I've about
> dou
> impact
> on the performance of the case that never needs any swapping at all
> first and foremost - then make swapping faster within that
> constraint...
>
> ...jim
>
> On 11/1/10 3:13 PM, Denis Lila wrote:
> > Hi Jim.
> >
> >
before was silly.
Regards,
Denis.
- "Jim Graham" wrote:
> Hi Denis,
>
> Good news!
>
> On 10/28/2010 3:27 PM, Denis Lila wrote:
> >> If we moved to a Curve class or some other way to
> >> consolidate the 3 lists (may be easier in native code), this mig
te:
> Hi Denis,
>
> On 10/26/2010 6:58 AM, Denis Lila wrote:
> >> 90% (guesstimate) of the time edges do not cross each other, thus
> if
> >> you sort the crossings without reordering the active edges then you
> just
> >> end up doing the same sorting wo
Hi Clemens.
It's interesting to note that this doesn't happen on OpenJDK, and
on closed java the subpixel hint is not necessary to reproduce this.
Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough.
Regards,
Denis.
- "Clemens Eisserer" wrote:
> Hi,
>
> While playing arround w
n the nextY processing for the very very
> common case.
I also implemented this some time ago. I didn't keep it because it slowed
things down a bit. However, I only tested it with very complex and large
paths, and in hindsight, I shouldn't have based my decision on that, so I
will re-implem
ome more about your other suggestion. I'll reply
to it tomorrow.
> How is that for "food for thought"?
Delicious :)
Regards,
Denis.
- "Jim Graham" wrote:
> Hi Denis,
>
> On 10/25/2010 7:34 AM, Denis Lila wrote:
> >> (and I have some i
> That's great. I will be pushing today.
About that: you wrote the TransformingPathConsumer2D file,
so how should you be given credit? Should I put your name in
"Contributed-by"? Should I put an @author tag in the file?
Or does the "reviewed-by" suffice?
Regard
1 - 100 of 187 matches
Mail list logo
