Hi Laurent,
A couple of comments that might just be points for clarification. Minimally it would make sense to include the JBS
report number on the third item below, but the rest are just notes and suggestions...
On 4/26/17 2:32 PM, Laurent Bourgès wrote:
- MarlinProperties - TileSize vs
Vote: yes
...jim
On 5/5/17 12:54 PM, Phil Race wrote:
I hereby nominate Laurent Bourges to membership in the 2D group.
This looks fine, but I've reached out to Phil with a question about changing the default and whether we need to file a
request for that.
Is there a JBS bug for this yet?
...jim
On 5/9/17 3:06 AM, Laurent Bourgès wrote:
Jim,
Here is the updated webrev:
http://c
This looks good. Approved...
...jim
On 5/16/17 2:12 PM, Laurent Bourgès wrote:
Hi,
Here is a (slightly) modified Marlin2D patch after synchronizing again with the
coming MarlinFX patch:
http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.3/
Changes:
- (D)Helpers:
Looks fine to me...
...jim
On 7/5/17 10:31 AM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk10.
Bug: https://bugs.openjdk.java.net/browse/JDK-8183576
Webrev can be found at: http://cr.openjdk.java.net/~serb/8183576/webrev.00
The method setRGB(int x, int y
This same thing is done in other places in a simpler way without creating an inner class simply by having createGE() do
the assignment and test for null, as in:
before:
public static synchronized GraphicsEnvironment
getLocalGraphicsEnvironment() {
if (localEnv == null) {
Hi Sergey,
On 7/25/17 12:53 PM, Sergey Bylokhov wrote:
In this variant the field should be volatile, and this will introduce some synchronization. Otherwise it will be
possible to read non-null value in localEnv while the constructor of GraphicsEnvironment was not completed on some other
thread
On 7/25/17 3:37 PM, Sergey Bylokhov wrote:
If that is the case then I think we have a few places where we do this "manual conditional synchronization" that
should probably be investigated. If I remember correctly, though, they may use the following paradigm which might not
suffer from that is
On 7/26/17 12:34 PM, Jim Graham wrote:
I'll do a search and see if there are any cases of the above paradigm left...
I did a basic grep over the Java sources in java.desktop looking primarily for synchronizations on a class, ignoring
synchronized methods (both instance and static
lGraphicsEnvironment(), possibly
with updating a specification? We have similar issues in other parts
of code which I would like to update later after this one.
Yes, I do think we can remove synchronized but we should do a CSR
(CCC)
On 07/25/2017 03:03 PM, Jim Graham wrote:
+1 for the inner clas
Will the tray icon canvas always be on the default screen? I believe the latest MacOS and Win10 both allow menu bars
and task bars on all monitors. Linux may not be far behind...
...jim
On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote:
Hi, Kindly review a fix for
e-existing condition"...
...jim
On 7/31/17 1:32 PM, Jim Graham wrote:
I adjusted one of the statements to be a little more straightforward and set the compatibility risk to minimal. If Phil
thinks the risk can be set to "None", that was my alternate, but
Hi Laurent,
I'm just reading through the code now to get a handle on the nature of the
changes...(and starting with the 2D version)...
[D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)?
[D]Dasher.java - why is there a new goto_starting() which is only used from one p
Hi Laurent,
On 8/28/17 2:09 PM, Laurent Bourgès wrote:
Hi Jim,
Thanks for your comments, it helped refining the webrev.
Here are my answers:
2017-08-26 2:22 GMT+02:00 Jim Graham mailto:james.gra...@oracle.com>>:
[D]Dasher.java - why the changes from (firstSegIdx > 0) to (fi
accuracy
(cups...)
Hope you will have time soon to look at the webrev, your feedback may help a
lot.
Cheers,
Laurent
Le 29 août 2017 2:58 AM, "Jim Graham" mailto:james.gra...@oracle.com>> a écrit :
Hi Laurent,
On 8/28/17 2:09 PM, Laurent Bourgès wrote:
Hi Jim,
the DDA stuff is just as good as any other technique for accomplishing that and since we have to do the DDA stuff
anyway, we can just piggy-back off of that. When it calls addLine(), we will reject each of its pieces individually...
...jim
On 8/31/17 12:45 PM, Jim Graha
First, consider what is handled inside the guts of the Renderer process.
- It doesn't need to process any segments above or below the clip, they have no impact on the rendered pieces inside the
clip
- It needs to process segments that are out-left only in so far as it needs to come up with a pro
pre-clip this" or "not" then this isn't really
needed - just add the necessary logic to Renderer instead...
...jim
On 8/31/17 4:15 PM, Jim Graham wrote:
First, consider what is handled inside the guts of the Renderer process.
- It doesn't need t
and
accurate whether the entire path is EO or NZ...
...jim
On 8/31/17 4:15 PM, Jim Graham wrote:
For the Even-odd filling rule, I think it needs exact segment intersections on the left side, so I am focused on the
Non-zero filling rule for now.
They are identical
Hi Denis,
On 8/23/2010 4:18 PM, Denis Lila wrote:
To widen cubic curves, I use a cubic spline with a fixed number of curves
for
each curve to be widened. This was meant to be temporary, until I could find a
better algorithm for determining the number of curves in the spline, but I
discover
Hi Denis,
On 8/24/2010 3:35 PM, Jim Graham wrote:
As far as flattening at the lowest level when doing scanline conversion,
I like the idea of using forward differencing as it can create an
algorithm that doesn't require all of the intermediate storage that a
subdividing flattener requires
etter by using
doubles).
Regards,
Denis.
- "Jim Graham" wrote:
Hi Denis,
On 8/23/2010 4:18 PM, Denis Lila wrote:
To widen cubic curves, I use a cubic spline with a fixed number
of curves for
each curve to be widened. This was meant to be temporary, until I
could find a
bet
straints leave just one unknown,
which
needs to be eliminated. I am not sure how to do this. I thought about making
the line
(p2',p3') be a distance of w from (p2,p3) (which is exactly what needs to be
done for
(p1',p2') and (p3',p4')) but this doesn't get us
o
the
x axis and then subdivide like I do now (i.e. make monotonic, break
at
inflections) or get rid of the monotonic subdivision, and instead
subdivide
by checking the angles of the control polygon. I could make it so it
subdivides whenever the angles between p2-p1 and p3-p2 or p3-p2 and
p4
On 9/2/2010 2:43 PM, Denis Lila wrote:
Actually, I had a question about the test I wrote which takes 20 seconds. When
I turned antialiasing on, the test dropped from 20 seconds to 2.5. This is very
puzzling, since antialiasing is a generalization of non-antialiased rendering
(a generalization whe
use one of the other pipes (not Ductus) for
non-AA and maybe it just isn't as good as Pisces?
We definitely use it for non-AA.
I traced it.
Denis.
----- "Jim Graham" wrote:
On 9/2/2010 2:43 PM, Denis Lila wrote:
Actually, I had a question about the test I wrote which takes 20
on-AA. Look at
LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo()
directed at a SpanShapeIterator...
I think there's a misunderstanding. All I meant was that, even when AA is off,
we do use pisces for widening, but it doesn't do any rasterization.
On 9/3/2010 6:03 AM, Denis Lila wrote:
the cost of the context switches into native and back for each path
segment dominate the performance of long paths.
I see. That makes sense.
It was something I was meaning to fix for a long time (when that code
was first written native code was so much f
considerably
easier too).
Regards,
Denis.
- "Denis Lila" wrote:
- "Jim Graham" wrote:
OK, I see. You were doubting that the "thing that came after
Pisces"
could be that much different considering that Pisces is rendering
many
more sub-pixel
morrow)
- in dasher, there are variables called sx1, sy1. They seem useless
to me. It would help a lot if they are. Could you please look at this?
If anything at all is confusing in it, please contact me (e-mail or irc:
I'm on OFTC #openjdk. My nickname is dlila).
Thank you,
Denis.
- "
On 9/14/2010 10:48 AM, Denis Lila wrote:
Hello Jim.
sx1,sy1 have lost their way along the way somewhere.
I think that was my fault:
Not entirely - see below.
I don't think you actually need sx1, sy1 - instead you need to buffer
and save aside the first set of dashes and I don't see that b
Hi Denis,
Sorry for being so distracted (on the other hand, it was for JavaOne
;-), but it looks like you made some incredible progress in the meantime!
On 9/22/2010 2:22 PM, Denis Lila wrote:
I also ran a 2D graphics test suite: http://icedtea.classpath.org/hg/gfx-test/
icedtea6 version 1.8,
Hi Denis,
On 9/27/2010 7:43 AM, Denis Lila wrote:
Hi Jim.
How much faster? I'm worried about this, especially given our tiled
approach to requesting the data. What was the bottleneck before?
(It's been a while since I visited the code - we weren't computing the
crossings for every curve in th
Hi Denis,
On 10/8/2010 8:53 AM, Denis Lila wrote:
2. I changed how the alpha map is managed in PiscesTileGenerator to
something that's a bit clearer and uses less memory (the latter comes
from changing the +300 in the alpha tile allocation to +1. If there was
a good reason for using 300, please
Hi Denis,
On 10/12/2010 6:01 AM, Denis Lila wrote:
Hi Jim.
2. I changed how the alpha map is managed in PiscesTileGenerator to
something that's a bit clearer and uses less memory (the latter comes
from changing the +300 in the alpha tile allocation to +1. If there was
a good reason for using 3
HI Denis,
I'm just now getting down to the nitty gritty of your webrevs (sigh).
On 10/6/2010 1:36 PM, Denis Lila wrote:
webrev:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
PiscesRenderingEngine.java:
line 278 - the det calculation is missing "b".
line 296 - is there an "ep
Hi Denis,
I took a little break from code reviewing to write up this concept which
might help simplify the PolyIOHelper stuff in your code (later). My
concept was that the attached "transforming PathConsumer" classes would
be potentially more efficient than putting the coordinates into a buff
Round 2
On 10/13/2010 3:40 PM, Jim Graham wrote:
HI Denis,
I'm just now getting down to the nitty gritty of your webrevs (sigh).
On 10/6/2010 1:36 PM, Denis Lila wrote:
webrev:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
Stroker.java:
Are you happy with the cu
Round 3...
On 10/6/2010 1:36 PM, Denis Lila wrote:
webrev:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
I'm going to set the rest of Stroker.java aside for a moment and focus
on other areas where I have some better knowledge...
Renderer.java:
lines 83, 91, 99: can't these
Round 4...
On 10/6/2010 1:36 PM, Denis Lila wrote:
webrev:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
BezCurve.java:
I'd add some "set()" methods to BezCurve/Curve and then use a scratch
instance in Renderer (and other places?) to reuse those calculations,
such as:
Cur
h - since we know the length is
relatively close to chord length, just compute the point on the curve at
t and then use the distance formula to the start point to compute the
arc length - no subdividing needed, just an eval and a linelen, and
bsBuf goes away...
...j
Hi Denis,
On 10/18/2010 2:21 PM, Denis Lila wrote:
Are you happy with the current variable names?
Not really. The names you suggested are much better. I'm using them now.
As for making a vector class, I think we should push this and then decide.
It's absence has already done most of the damage
On 10/19/2010 10:38 AM, Denis Lila wrote:
Hi Jim.
If I haven't replied to a suggestion, that means I've implemented and
I thought it was a good idea, so I don't have anything to say about it.
That's mostly true too for me, but there are a couple that I might go
back to - I'll let you know whe
Hi Denis,
On 10/19/2010 10:40 AM, Denis Lila wrote:
ROCsq - I looked at the wikipedia article and it wasn't clear how it
directly related to your function since the article is dealing with
the curvature of a function graphed against its own t, but you are dealing
with 2 parametric equations comb
Hi Denis,
On 10/19/2010 10:40 AM, Denis Lila wrote:
Actually, I wrote a simple program to make sure the radius of curvature
function was correct. I have attached it. It's not a proof, but I think
it is convincing. Just hold down the mouse button and move it horizontally.
This will change the t v
Hi Denis,
On 10/18/2010 2:21 PM, Denis Lila wrote:
I introduced a drawRoundCap method. This eliminated the side argument from
the round join drawing, which made it easier to eliminate the trig function
calls. I did this by using dot products to compute cosines (which was possible
because now Str
Hi Denis,
One clarification:
On 10/20/10 7:11 AM, Denis Lila wrote:
When would the isCW test trigger? Does it track "rev"? What happens
at 180 degrees (is that test reliable for the randomization that might
happen when omxy are directly opposite mxy)?
isCw is used for computing the arc bise
On 10/20/10 7:54 AM, Denis Lila wrote:
In #2, you have a bunch of "I'() || B'()" which I read as "the slope
of the derivative (i.e. acceleration) is equal", don't you really mean
"I() || B()" which would mean the original curves should be parallel?
Otherwise you could say "I'() == B'()", but I th
ev at all. It just checks
to see on which side of the (omx,omy),(mx,my) chord the computed (mmx, mmy)
is.
Regards,
Denis.
- "Jim Graham" wrote:
Hi Denis,
One clarification:
On 10/20/10 7:11 AM, Denis Lila wrote:
When would the isCW test trigger? Does it track "rev"
2,0), and the vectors
(2,0) and (2,0) are parallel.
Does this make more sense?
Regards,
Denis.
- "Jim Graham" wrote:
On 10/20/10 7:54 AM, Denis Lila wrote:
In #2, you have a bunch of "I'() || B'()" which I read as "the
slope
of the derivative (i.e. acce
Hi Denis,
I'll be focusing on this later today, just a last proofread.
In the meantime, can you outline the tests that you ran?
Also, have you used J2DBench at all? I know you ran some of your own
benchmarks, but didn't know if you were familiar with this tool:
{OpenJDK}/src/share/d
Hi Denis,
I saw something in the latest webrev that reminded me of an earlier comment.
On 10/18/2010 2:21 PM, Denis Lila wrote:
line 389 - The test here is different from closePath. What if they
were both "prev == DRAWING_OP_TO"?
I am now using prev!=DRAWING_OP_TO (not ==, since it is suppos
oveto,close? (Or close,close?)
...jim
On 10/21/2010 6:10 PM, Jim Graham wrote:
Hi Denis,
I saw something in the latest webrev that reminded me of an earlier
comment.
On 10/18/2010 2:21 PM, Denis Lila wrote:
line 389 - The test here is different from closePath. What if
00 - technically, this could be [0] and [1] since all points on
the curve are the same. ;-)
line 805,810 - abs()?
line 821,824 - you add 1 to nCurves just to subtract 1 later? Maybe
rename it to nSplits and skip the +/-1?
...jim
On 10/21/2010 1:52 PM, Jim Graha
Hi Denis,
Interesting results. Note that sun-jdk7 is already showing some
regressions so the more intesting results are the old-to-new pisces
comparisons. It's interesting to note that non-AA dashed ovals took a
much bigger hit than AA dashed ovals so we need to see which code is
fielding t
On 10/22/2010 12:22 PM, Denis Lila wrote:
Because the error is meant to be relative. What I use is supposed to be
equivalent to difference/AverageOfCorrectValueAndApproximation< err,
where, in our case, AverageOfCorrectValueAndApproximation=(len+leafLen)/2,
so that multiplication by 2 should hav
Hi Denis,
On 10/25/2010 7:34 AM, Denis Lila wrote:
(and I have some ideas on further optimizations to consider if you are still
game after this goes in)...
I'd love to hear what they are.
Here are my thoughts:
- Currently Renderer has more stages than we probably should have:
for (each
Hi Denis,
Just to be certain - you are still planning on putting the existing
stuff back and we're talking about future work, right? I'd love to get
a stake in the ground here.
On 10/25/2010 3:30 PM, Denis Lila wrote:
- Create a curve class and store an array of those so you don't have
to i
On 10/26/2010 6:58 AM, Denis Lila wrote:
If we are really worried about the y-sort, then how about creating a
bunch of buckets and doing a bucket sort of the edges? As they are
added to the list of segments, we accumulate their indices in a row
list based on their startY so that each step of the
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 work (same swaps) on the next scanline. My
SpanShapeIterator code actual
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 might win
in more cases...
Does that mean you no longer think we should flatten every curve as soon
as we get it?
No,
SRC behaves like SRC, but AA is another part of the equation. It works
like this (for any rule):
blendresult = PORTER_DUFF(rule, rendercolor, dstcolor, extraalpha)
// For SRC, blendresult = rendercolor modulated by extra alpha
storedresult = INTERP(dstcolor, blendresult, aacoverage)
// For full
Why is SRC with an extra alpha handled any differently than SrcNoEa with
a color that has alpha? The two cases are supposed to be folded
together because it doesn't matter where the alpha comes from.
There is also a paintType indicator that indicates when the paint is
opaque. If you only reg
If you allow ALPHACOLOR (paintState <= ALPHACOLOR) then you should be
able to handle Src with EA...
...jim
On 10/29/10 12:49 PM, Phil Race wrote:
This fixes it, although the same may need to be done to OGL and D3D
subclasses
of SurfaceData.java
-phil.
diff --git a/src
would be good if it's because of the casts because
it would no longer be an issue when we convert to native.
I alo made an unrelated change: I now find the orientation and update x0,y0
much earlier than we used to. The way I was doing it before was silly.
Regards,
Denis.
- "Jim Gra
sier (for me - I haven't been able to make OProfile work
for java yet).
Regards,
Denis.
- "Jim Graham" wrote:
Hi Denis,
A generic suggestion - make all of your classes final - that gives the
compiler the maximum flexibility to inline any methods you write.
With respect to
Hi Denis,
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 doubled
(like the possibility of using SIMD or when value-types
would be a huge benefit), it has its own performance pitfalls
especially if the workload is small and things like Get*ArrayCritical
cause scalability problems because they have to lock the GC.
Well, Jim Graham said that a native version of
It's still a work in progress, but I've cleaned up a lot of logic and
made it faster in a number of ways. Note that I've abstracted out the
cache stuff and created an "AlphaConsumer" interface which may evolve
over time.
In FX we actually consume alphas in larger chunks than the code in JDK
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 AFD variables a
Also, some things to note in the new version - things I had to "fix" not
related to performance.
In endRendering the pixel bounds of the edges needed to be computed and
passed along to the next stage. Unfortunately the code in endRendering
computed the sub-pixel bounds and then simply shifted
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 realized this years ago
when I was writing my Area code (see sun.awt.geom.Curve) and put in
tweaking code to make them monoton
l the way to the last
(or beyond) scanline. Is this really common enough that we gain by
treating it as a special case? Would it not be better to assume that
every bucket needs pruning and save some memory (and possibly resulting
in better cache performance)?
Thanks,
Denis.
- "Jim Graham&q
Hi Denis,
On 11/9/2010 3:06 PM, Denis Lila wrote:
I see. In that case, I think it's a good idea if we don't make curves
"monotonic". I already did this, by moving the edgeMin/axX/Y handling
and orientation computations in addLine. This did make it slower compared
to the file you sent me, but onl
ink these
would
be too bad, because mostly they're just going to be all 0 so they will
be skipped because getTypicalAlpha() is now implemented.
How do you think we should handle these 4 variables?
Thank you,
Denis.
- "Jim Graham" wrote:
Hi Denis,
On 11/8/2010 2:39 PM, Denis Lila wrote:
ersion 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:
...jim
On
t, I apologize for this e-mail.
Anyway, here's the e-mail:
http://mail.openjdk.java.net/pipermail/2d-dev/2010-November/001654.html
I also just found a bug in the cubic roots math: in the case where the function
was quadratic, I was forgetting to filter the computed roots to include
only ones in the range [A, B).
Regards,
Denis.
- "Jim Graham" wrote:
This is a forward port of some fixes I made in 6u12 to make transformed
rectangles and wide lines go fast by implementing "Parallelogram"
rendering pipelines and loops.
There will be a follow-on fix for AA rectangles and wide lines coming.
This was the first stage that teaches the basic graphi
On 12/1/2010 5:42 PM, Jim Graham wrote:
This is a forward port of some fixes I made in 6u12 to make transformed
rectangles and wide lines go fast by implementing "Parallelogram"
rendering pipelines and loops.
There will be a follow-on fix for AA rectangles and wide lines coming.
Thi
Hi Denis,
On 12/6/2010 4:21 PM, Denis Lila wrote:
Hi Jim.
line 134 - what if numx or numy == 0 because only roots outside [0,1]
were found?
In this case lines 151-162 will execute, and nothing is wrong. The only
problem is when both numx and numy are 0. This is certainly possible in
the gene
Hi Denis,
On 12/7/2010 10:47 AM, Denis Lila wrote:
Hi Jim.
I'm sure you will likely find a root, but the method you are using is
"roots*inAB*" which may throw the root out because it is out of range,
no?
I'm sure some roots will be thrown out, but I think in every call of
getTCloseTo there w
On 12/8/2010 9:37 AM, Denis Lila wrote:
Shouldn't it be [A, B]?
I thought about this when implementing it, but I don't think it mattered
whether it was closed or half open, and the closed interval would have been
somewhat more awkward to implement.
I'm not sure how the closed interval is awkw
Hi Denis,
On 12/8/2010 12:04 PM, Denis Lila wrote:
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 int
By "without this optimization" do you mean back when you did a full scan
for the proper T? Then this is great news!
How often do we end up needing getTCloseTo in practice?
...jim
On 12/8/2010 1:54 PM, Denis Lila wrote:
Hi Jim.
How about "if the 3 segments of the con
On 12/10/2010 8:27 AM, Denis Lila wrote:
Hi Jim.
Yes. The improvement shown by the bench marks is substantial.
Then this is great news!
Indeed :-)
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
Hi Denis,
The example I gave was intended to be very crude - I was simply
describing the technique, but as I said it would require better math to
really know what the right formula would be.
With respect to finding a cubic root, currently you are doing that in 2
dimensions, but what if we co
On 12/13/2010 10:54 AM, Denis Lila wrote:
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
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)?
Also, one area that I had issues with the version I used in CC2D was
that it chose a hard cutoff to classify th
Hi Denis,
Those sound like just the kind of problems I believed existed in the
CC2D algorithm.
You might want to submit it as a separate push and get credit for fixing
4645692 (solveCubic doesn't return all answers), and maybe even the
following failures in the containment methods (which cou
This is a forward port of the second half of the fixes in 6u12 for doing
fast transformed rectangles and wide lines. This time the AA pipelines
are upgraded to handle parallelograms directly and some new native loops
are added to do direct rasterization of AA parallelogram filling and
stroking
Hi Denis,
On 12/14/2010 5:11 PM, Denis Lila wrote:
I have one question though: how fast does this have to be? I can come
up with fairly reasonable examples for which both CubicCurve2D.solveCubic
and the implementation I found give very inaccurate results
The existing method was not very accura
Hi Denis,
That sounds like some very good ideas for making this method very accurate.
On the other hand, we're starting to get into the territory where an
advanced math package should be catering to these requirements. The
solveCubic was an internal helper function for implementing the hit
t
Hi Denis,
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
rather
Hi Andrew,
Do you really need the "= NULL" on the declarations? They are
initialized on the following line, that should be good enough for any
compiler or lint processing.
Other than that, the new fix looks good...
...jim
On 12/21/2010 2:57 AM, Steve Poole wrote:
2010 0:09, Jim Graham wrote:
Hi Andrew,
Do you really need the "= NULL" on the declarations? They are
initialized on the following line, that should be good enough for any
compiler or lint processing.
Other than that, the new fix looks good...
...jim
On 12/21/2010 2:57 AM, Steve Po
Hi Denis,
Line 1099 - I decided to check out Cordano's method and noticed a
discrepancy. The comment here says we are calculating the p and q for
this equation, but the values assigned to the p and q variables in lines
1102,1103 happen to be p/3 and q/2. That's fine because almost all of
th
The regression tests for this bug do not call the method directly. They
may exercise the function indirectly in some pipelines, but not all
pipelines will use this method (the current version of Pisces in OpenJDK
doesn't even use it until you integrate your other changes as far as I
know).
I
Aha!
I finally figured out what I was missing.
On 12/24/2010 4:43 PM, Denis Lila wrote:
Line 1133 - I don't understand why that term has -q in it. The above
link and the original code both computed essentially the arccos of
this
Basically, the negative comes in when you push all of the p term
Hi Denis,
I'm attaching a test program I wrote that compares the old and new
algorithms.
Obviously the old one missed a bunch of solutions because it classified
all solutions as 1 or 3, but the new one also sometimes misses a
solution. You might want to turn this into an automated test for
Correction...
On 12/28/2010 3:00 PM, Jim Graham wrote:
math. (Though it begs the question - is "-q/sqrt(-p^3)" more accurate
than "-q/(p*sqrt(-p)"? If p is < 1 then the cube is an even smaller
number, does that matter?)
Make that "-q/(-p*
1 - 100 of 822 matches
Mail list logo
