>
>
>
> We should also be wary of compiler options that are a win on one processor
> family and a loss on another. Anything that schedules instructions may be
> specific to a particular generation of CPUs, for instance. Or for i5 vs i7
> vs M(obile)...
>
> ...jim
>
>
Hi Mike,
This bug is fixed for some time and the recent jdk9 b110 contains the fix:
https://jdk9.java.net/download/
Regards,
Laurent
Le 2 févr. 2016 19:27, "Mike Bremford" a écrit :
>
> Hi All
>
>
> I was steered to this list after initially posting here:
https://community.oracle.com/message/13
Jim,
Jim, here are my comments:
2016-02-04 2:55 GMT+01:00 Jim Graham :
> Interesting, so this can happen with any custom Paint or Composite. Yes,
> re-entrance detection should be done.
>
FYI, I proposed a bug fix and also checked the output images are now
correct:
http://mail.openjdk.java.net/p
Phil,
bug https://bugs.openjdk.java.net/browse/JDK-8148886
Thanks for creating the bug !
I spent some time tracking down the bug and make the diagnostic:
1. I enabled diagnostics:
*-Dsun.java2d.renderer.log=true*
*-Dsun.java2d.renderer.doChecks=true*
-Dsun.java2d.renderer.doStats=true
-Dsun.
#x27;ve got it and I'll delete it.
>
> Cheers... Mike
> --
> -
> Mike Bremford - CTO m...@bfo.com
> Big Faceless Organization http://bfo.com
>
> On 2 February 2016 at 19:02, Laurent Bour
Hi,
Please send me your test case at bourges.laurent (gmail).
I need it to reproduce your issue.
Thanks,
Laurent
Sergey,
>> So it looks scalar operations on vector (4) ie vectorization should be
>> applicable.
>
>
> yes, I think so.
I googled a bit and it seems tricky to implement alpha blending with sse2
but many projects succeeded by using writing directly sse2 primitives !
>> Maybe the conditions (pathA
Sergey,
Did you made any progress ?
I finally looked at the preprocessed C code and also enabled
ftree-vectorizer-verbose output:
CFLAGS := -save-temps -ftree-vectorize -ftree-vectorizer-verbose=2
$(CFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \
I looked at the IntArgbPreSrcMaskFill hotspot (in my Elli
Sergey,
Thanks a lot for your advices, I will definitely try your approach to read
the 'preprocessed' C code (as I do not like much macros).
I think I will have some time during winter holidays to implement correct
gamma correction = pow(2.2), blend then pow(1/2.2) (using precomputed
tables) in t
ergey Bylokhov" a
écrit :
>
> Right now I am trying to investigate where the code is affected by these
options, and also I am trying to investigate possibility of code
improvement.
>
>
> On 27.11.15 13:28, Laurent Bourgès wrote:
>>
>> Hi,
>>
>> Just a reminder
Jim,
I should create a new bug concerning both Marlin & Pisces but I prefer
discussing the problem first.
A Marlin user reported me an issue with (text outline) rendering artefacts
(due to partial cleanup in arrays).
Using Marlin with -Dsun.java2d.renderer.doChecks=true (logs re-enabled), we
dete
Sergey,
2015-11-27 12:07 GMT+01:00 Sergey Bylokhov :
> Right now I am trying to investigate where the code is affected by these
> options, and also I am trying to investigate possibility of code
> improvement.
>
Good to know you are working on that !
Which gcc version are you using ?
Looking fo
+ _SIZEOF_EDGE_BYTES);+
((long)edgePtr) + _SIZEOF_EDGE_BYTES);
The CrashTest passes again after the fix (automated tests are very cool) !
Laurent
2015-11-27 12:18 GMT+01:00 Laurent Bourgès :
> Hi Jim,
>
> Here is a simple fix on potential overflow in ArrayCache.getNew
Hi Jim,
Here is a simple fix on potential overflow in ArrayCache.getNewLargeSize()
discussed during Marlin integration:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s6.0/
I added the ArrayCacheSizeTest class which now passes in jtreg.
Could you create a bug, I am not sure what I should fil
Hi,
Just a reminder on this compiler issue.
I tested today the impact of the proposed patch changing compiler options
for AWT on my machine (i7 gcc 4.8.4):
Without patch (clean build - client libs):
EllipseTests-fill-true.ser 125445.220
445.336445.1960.127
...
>
> On 11/25/15 12:36 AM, Laurent Bourgès wrote:
>
>> Hi,
>>
>> I looked at the 2d group page you sent by email and it is OK.
>>
>> However, the 2d group page is still not updated online whereas the GR
>> page is OK !
>
>
Hi Jim,
It seems that your changes made on the java2d patch (webrev.01) are not
present in the GR repository.
See:
http://hg.openjdk.java.net/graphics-rasterizer/jdk9/jdk/
Could you merge (back) ? or later ...
PS: I am synchronizing all my Marlin variants on my laptop (GR, github
branches ...)
lin...
>
> ...jim
>
> On 11/24/15 6:24 AM, Laurent Bourgès wrote:
>
>> PS: You should update the openjdk wiki pages later:
>> http://openjdk.java.net/projects/graphics-rasterizer/
>> http://openjdk.java.net/groups/2d/
>>
>> "As documented on the group pag
Hi Jim,
I finally got the Marlin rasterizer integrated into the JDK9 client repo.
>
Excellent !
Thanks a lot for your work in the last days to make it happen.
> I fat-fingered the first integration and forgot to include "-u lbourges"
> so Phil and Kevin and I sat on the phone and created a back
Hi Jim,
Sorry I sent the message partially edited by mistake.
> The point is that the hard failure is a condition of when we need more
than we can provide, not when we "already have" more than we can provide.
needSize should cause the hard failure, not the current size. And if
needSize is going
Hi Jim,
>> I'm code reading now:
>>
>> ArrayCache.java, line 205 - should that be needSize there? Also,
>> should these tests be > or >=?
>>
>> I wanted to limit the size to 2M (Integer.MAX_VALUE) but it wanted 2
>> passes: first, return 2M, then if more needed, fail !
>> If prefer us
Jim,
Here are few answers to several questions during last friday's sprint:
> I ran a bunch of tests on 4.2 and saw no issues and the performance looked
> good. There were still some things that Ductus was faster on, but I just
> did a brief run of a few tests I cobbled together so I don't know
follow it up with a small cleanup:
>>
>> - blessed modifier order script
>> - switch to new jdk.internal.misc.Unsafe class
>> - turning off verbose
>> - switch default renderer to Marlin
>> - add RenderingEngine flag to print out RenderingEngine class chos
gt;> - switch to new jdk.internal.misc.Unsafe class
>> - turning off verbose
>> - switch default renderer to Marlin
>> - add RenderingEngine flag to print out RenderingEngine class chosen
>> (-Dsun.java2d.renderer.verbose=true)
>>
>> Then I'll generate a webrev against the client JDK and send that out for
>> review to the 2D list...
>>
>> ...jim
>>
>> On 10/19/15 7:06 AM, Laurent Bourgès wrote:
>>>
>>> Hi Jim,
>>>
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.2/
Jim,
> My goal is to be able to publish a webrev to the 2D mailing list by
tomorrow so hopefully I'll see a diff soon.
Excellent news !
It would be nice to have a webrev against the GR forest and also a webrev
against 4.2 to streamline reviewing.
I sent you a webrev against the GR forrest on my
One more thing:
Did you agree with phil to make Marlin the default renderer for both
OpenJDK and Oracle JDK (closed source) to obtain the maximum exposure very
early ?
Laurent
Jim,
Here is the new webrev Marlin #4.3:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.3/
Changes:
- MarlinCache: fillRLE only: I clear both arrays (alphaRow...) inline as
only few values are expected => 10% better !
- Fixed minor bugs, unused imports and system.out.println calls ...
- ad
Hi Jim,
Good to see it is moving forward.
> I am going to move forward with intent to get this version 4.2 into the
client repos as the version we will go into Feature Complete milestone
with. Let me know if there is a more recent version I should be looking at.
I will publish a new webrev asap
Jim,
Just a reminder: could you review the last marlin patch 4.2 (10/19) ?
> >> 1. Do you prefer I send you another webrev including my last changes ?
> >
> >
> > Let me look through the latest webrev first.
>
> Ok. FYI new changes are very small.
If you want, I can send you an up-to-date webrev
Jim,
I retrieved repository changes and made a full clean & build.
MarlinUtils does not compile anymore as SharedSecrets was move to
jdk.internal.misc.
I fixed it in my working copy and it works well.
Moreover, I did not find neither the new Unsafe nor the new Cleaner
implementations: I guess it
Hi Jim,
>> 1. Do you prefer I send you another webrev including my last changes ?
>
>
> Let me look through the latest webrev first.
Ok. FYI new changes are very small.
I started writing the CrashTest class testing several corner cases with
huge images & paths to force growable arrays to resize
Laurent Bourgès :
> Hi Jim,
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.2/
>
> I added the OffHeapArray class used by Renderer and now by MarlinCache to
> store rowAAChunk data.
> Moreover I performed other small optimizations (heuris
Jim & Phil,
Thanks for promoting Marlin !
> I'm only doing a HiDPI talk, but Phil is making slides for the JDK/JavaFX
overview BOF so perhaps he should mention it there. Note that he will
likely already have a list of JEPs for 9, so it should already be listed...
Maybe we should see if Marlin p
Jim & phil,
Could you, or someone else, present or at least mention our efforts on the
Marlin renderer during the JavaOne conference ?
That would be great to have some feedback and interesting use cases for
multithreaded rendering.
Regards,
Laurent
Hi Jim,
Here is the new webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.2/
I added the OffHeapArray class used by Renderer and now by MarlinCache to
store rowAAChunk data.
Moreover I performed other small optimizations (heuristics,
Renderer.addLine() split in 2 methods) and many ben
Sergey,
Could you please fill a new bug related to the libawt compilation on linux ?
As it concerns awt and not only Marlin, I would prefer to let you or
anybody else handle this issue.
To sum up:
We observed performance loss between jdk8 and jdk9 on Maskfill (c software
loops).
I provided the
Hi Jim,
Here is below the webrev I prepared last saturday night.
However, I made progress since as I inlined few methods and now use Unsafe
for rowAAChunk storage (to save few percents avoiding bound checks).
*So please, just have a look to see the new hybrid approach but do not make
a full revi
Jim,
FYI I worked on improving Marlin patch #4 to send you asap a new webrev: it
will be simpler with only 2 variants (uncompressed and RLE+blockFlags).
I also fixed a bug in the array cache related to crossings (ptrLen !=
ptrEnd) in Renderer.endRendering () and wrote a test that makes all cached
Sergey,
thanks for the information:
I tried your gcc options on my ubuntu 14.4 (v4.8.4) and it is actually
>> slightly faster: 10% on my fill ellipse test (450ms vs 490ms).
>>
>
> I tested by your jmh test, and the difference became bigger on 1400 size.
>
Interesting; I will try too.
>
>> Do y
Sergey,
I tried your gcc options on my ubuntu 14.4 (v4.8.4) and it is actually
slightly faster: 10% on my fill ellipse test (450ms vs 490ms).
Do you know which gcc compiler and options are used to build JavaSE EA?
Moreover, the linux distrib may define default options.
I will try to figure out
Jim,
Thanks for your ideas below:
> Some thoughts - we record some info on each scanline - mostly about the
new edges that are added. Perhaps we could keep deltas of how many edges
come and go per scanline and then sum them up at the start to figure out if
any scanline has a lot of crossings?
I
Sergey,
Thanks for having tests.
What is the units of your your results ?
I guess it is on the time axis: slower values are better.
How did you hack the gcc options in the openjdk build scripts ?
I could try on my local build too.
Bye,
Laurent
Le 1 oct. 2015 17:39, "Sergey Bylokhov" a
écrit :
Jim,
> As far as why the software loops are slower...
>
> Did any command line options change for compiling IntArgbPre.c? Touch
the file and rebuild and verify if the compiler options are the same (and
that both builds use the same compiler)...
To avoid all possible side effects, I deliberately
ce code and compared the libawt / java2d / loops /
vis_IntArgbPre_Mask.c from openjdk8 and openjdk9 but those are the same !
Can it be a JNI issue or a compilation issue (gcc settings ...) with that
native code ?
Any idea, Sergey ?
Thanks for the tips,
Laurent
2015-09-24 4:17 GMT+02:00 Sergey Bylokho
Jim,
I would like your point of view on the new algorithms to store alpha values
efficiently and some advices on heuristics / metrics to make the adaptive
approach more efficient / robust.
I hope having some spare time soon to spend on improving this patch...
Here are few more explanations that
Jim,
Here is the first webrev improving copyAARow() on large shapes (pixel
loops):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.0/
Note: I also incorporated few changes related to force cleanup in case of
runtime exception happening within pathTo(): see MarlinRenderingEngine,
Stroker, D
Jim,
I pushed the patch #3 after sync + build + test again.
Thanks,
Laurent
hort version - looks good to go, consider the following input at your own
> discretion and go ahead and push.
>
Excellent.
Here are my comments:
>
> Reviewing s3.4:
>
> On 8/17/15 2:34 PM, Laurent Bourgès wrote:
>
>> Changes:
>> - Renderer: remove unused D_ERR_STEP_MA
Jim,
2015-08-25 22:39 GMT+02:00 Jim Graham :
> If you'll give me a few minutes, I'll synch the repo before this goes in...
>
Ok, I was just typing 'hg push' ...
PS: I will answer your email meanwhile...
Laurent
t is good now, I plan to work soon on the Array Cache & dispose code.
Here are my comments to your emails:
1st email:
2015-08-13 22:32 GMT+02:00 Jim Graham :
>
> On 8/10/2015 2:15 PM, Laurent Bourgès wrote:
>
>> Jim,
>>
>> Here is the new webrev including your
Jim,
Here is the new webrev including your proposals to use 32.31 fixed-point
maths and double-precision in addLine() as it is definitely better:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s3.3/
I also fixed all findbugs warnings or added a comment / TODO to few of them.
Changes:
- Array
Jim,
One stupid question related to accuracy:
- should we have 2 distinct rendering pipelines : 1 based on floats (for
speed), 1 using doubles for increased precision and accuracy ?
Maybe we could use the java2d rendering hint QUALITY to decide which
pipeline to use... however this hint is for now
Jim,
I advocate I simply made a port of your FP approach in ShapeSpanIterator.c
without really understanding well the equations to adjust the edge to pixel
centers.
If there is a precision issue, it is also impacting the ShapeSpanIterator.c
!
Your recent proposal is very interesting (32.32 FP) as
Dear all,
I submitted a JEP to use the Marlin renderer instead of Pisces to improve
both performance, scalability and also quality.
FYI Marlin is in development for few months within the graphics rasterizer
project.
Please look at the JBS bug JDK-8131760 for more details:
https://bugs.openjdk.ja
(ddx, ddy) fails for negative values !
PS: I am now adjusting (lowering) the threshold to achieve better quality
without having too much performance loss.
I will be on vacation next week, but I may read emails but less often.
Cheers,
Laurent
Le 21 juil. 2015 23:33, "Laurent Bourgès"
Jim,
Here is the first webrev including the new rounding approach:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s3.2/
1. It is based on your fixed-point approach and use FloatMath ceil_int /
floor_int for perfomance.
I shift the subpixel y coordinates by - 0.5 in tosubpixy() as mentioned.
Jim,
>> Will try asap, maybe tonight. I mean I will shift coordinates early in
>> tosubpixx() and tosubpixy () by -0.5f.
>
>
> Good point. It could probably still be done by the same transform, but
it makes sense (and improves code independence) to keep it isolated in the
Renderer class instead.
Jim,
>> Few ideas to discuss:
>> 1/ I wonder now if the gridding = ceil (x/y - 0.5) should be done
>> differently: why not apply the offset to - 0.5 to points before curve
>> decimation or adding lines: it may saves a lot of substractions:
>> AddLine (x1,y1,x2,y2) implies 4 substractions whereas l
Jim,
Here are some news before leaving for a long week end:
> It uses FloatMath.ceil() that internally use the ceil_int()
implementation for performance.
> I agree it should use directly the ceil_int() to be more explicit.
I did it and made some tests with endRendering () disabled to evaluate th
Jim,
>
> I made an initial stab at a prototype of some cache management classes
that I think might aid in maintenance:
>
> http://cr.openjdk.java.net/~flar/MarlinArrayCaches/webrev.00/
>
Your prototype is interesting and I better understand your design.
However, I had no time yet to play with it
Hi again,
I feel as if this much effort put into creating fast alternatives for these
> operations is an interesting academic pursuit, but we might be better
> served by analyzing how we use floor/ceil and finding was to reduce those
> or find more targeted algorithms for those on a case by case b
Jim,
>
> Interesting numbers. It was hard to read the formatting on the diff
> below, but I got the gist of what was happening.
>
Sorry for the bad formatting but you had a chance to understand what I did:
great !
>
> Were the ceil(coord) measurements taken with the new ceil_int() code? For
>
Jim,
I have made the mentioned tests: it means I modified addLine() and
endRendering methods:
1/ use proper and consistent ceil(coord - 0.5) as you did in openpisces
(FX) :
Renderer.USE_CORRECT_RND=true
The output images are different from Pisces ones but are now closer to
Ductus ones = more ac
Jim,
Here is an updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s3.1/
Changes:
- enabled CHECK_NAN and CHECK_OVERFLOW to be correct for now
- renamed faster alternatives as int ceil_int(float) and float
floor_int(float) that are faster in the integer domain
- restored ceil_f /
Jim,
Sorry I did not merge the 2 mails!
>> Maybe DDA or floor (val) or ceil (val + 0.5) should be used instead in
>> both places ?
>
>
> I'm not sure how DDA impacts this since it is simply a formula for
computing the exact location where the curve crosses the scanline. Either
way we need to some
Jim,
> I take it the comments are copied from StrictMath and so the code may not
always follow their guidelines (if you set CHECK_NAN to false for instance).
Yes you're right: comments should be updated. Float values are expected to
be in MIN/MAX integer domain including NaN and +/- Infinity.
Ma
Jim,
I answer here to your two mails:
"
By "bucket 0 sizes", I meant the size of the array in the first resize
bucket, not the literal number 0.
My thoughts were that we would simply initialize the arrays to the smallest
of the cached growable array sizes. This would eliminate even more cases
w
Jim,
Here is a new webrev to improve FloatMath:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s3.0/
I tested it with following float values:
floats = [-2.13422758E9, -1.37992608E8, -134758.4, -131.5, -17.2,
-1.9, -0.9, -1.0E-4, -1.0E-8, -1.0E-23, -100.0, -3.0, -1.0, -0.0, 0.0, 0.0,
1.0
Jim,
here are the benchmark results:
- REF: Marlin reference = initial capacity tuned for arrays and
OffHeapEdgeArray
- NO_INITIAL: initial arrays = [0]
- NO_INITIALS_OFFHEAP_16: initial arrays = [0] and OffHeapEdgeArray(16)
I pushed all details (stats & benchmarks):
http://cr.openjdk.java.net/~l
Hi Jim,
>> I will now try being more opened minded to your valuable comments to
>> improve code maintainability without sacrifying too much the performance
>> level.
>
> It's a philosophy, not a hard requirement. And it is more important in a
large project, especially Open Source where you get ne
review again the array
cache / reset state code and tried some simplifications (postponed to #3).
On 6/12/15 5:45 AM, Laurent Bourgès wrote:
>
>> A general thought - should we have foo_initial arrays if we are
>> getting everything from a cache?
>>
>> I adopted thi
a new webrev. Is
>> there one? I think the existing array stuff is probably OK and I'll
>> look at it again now that I understand the tradeoffs of the current
>> design of it, but I wanted to know if there was a newer webrev for me to
>> review based on those other m
e algorithms without having to constantly worry
> about how we might disrupt a fragile caching scheme.
>
OK, I can work later on a new framework:
- ArrayCache abstract class where is byte[], int[], float[]
- CleanArrayCache extends ArrayCache = clean arrays
- DirtyArrayCache extends ArrayCach
Jim,
The reason I ask is that it would be against all odds that you'd be able to
> detect loading those 2 variables into temp local variables given how
> complex a given rendering operation is.
>
I agree that I also doubt to be able to detect such very subtle code change
in my benchmarks.
Howeve
Jim,
>> Fixed but I kept the local variable as it has a measurable impact (760ms
>> vs 800ms) with a medium complex map (135 000 shapes).
>
>
> Please confirm that I am reading this correctly.
>
> You reverted the 2 variable loads at lines 1258,1259 in Renderer.java and
made no other changes and s
Jim,
Here is the new webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s2.2/
CollinearSimplifier:
>
>>
>> Looks good. I'm still curious why you didn't use an enum - is the
>> code more efficient just dealing with basic numbers rather than enum
>> instances?
>>
>>
>> I did no
Jim,
I sent by mistake the wrong alternative floor / ceil implementations:
the NaN case was buggy (wrong not) !
Here are my test output (CHECK_OVERFLOW = true):
floats = [-2.13422758E9, -1.37992608E8, -134758.4, -131.5, -17.2,
-1.9, -0.9, -1.0E-4, -1.0E-8, -1.0E-23, -100.0, -3.0, -1.0, -0.0
Hi Jim,
Here are my comments:
ArrayCache.get*Bucket() - you decided not to do the shift method?
>>>
>>
>> I gave up: Do you think it is worth as there is only 4 buckets (ie few
>> if) ? Do you have an implementation to propose ?
>>
>
> Once I realized it was exponential growth I realized why you
Hi Jim,
Your proposal is interesting: I would have loved doing such smart array
cache for general use !
Do you think such a general ArrayCache would be helpful for other java2d or
jdk algorithms needing intensive array allocation ?
However, I focused mostly my work on getting the maximum performa
Dear Jim,
thanks for your detailed review, it took me some time to make the
appropriate fixes and publish a new webrev including white space changes
(-b):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s2.1/
Please read my comments below:
> Let me see if I understand up front what the cachi
s the one tracking the SQE effort...
>
> ...jim
>
>
> On 5/13/2015 9:59 AM, Laurent Bourgès wrote:
>>
>> Jim,
>>
>> Do you have time soon to review the second marlin patch ?
>>
>> Any other remaining comment on the first one ?
>>
>>
...jim
>
> On 5/13/2015 9:59 AM, Laurent Bourgès wrote:
>
>> Jim,
>>
>> Do you have time soon to review the second marlin patch ?
>>
>> Any other remaining comment on the first one ?
>>
>> Did you have news from the SQE team?
>>
>>
intermediate segments for joins & caps)
Laurent
Le 29 avr. 2015 22:27, "Laurent Bourgès" a
écrit :
> Jim,
>
> Here is a new webrev for the second step on the marlin renderer:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-s2.0/
>
> Changes:
> - ArrayCache: clea
Jim,
Here is a new webrev for the second step on the marlin renderer:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s2.0/
Changes:
- ArrayCache: cleanup in the growth algorithm + fixed TODO
- Float/Int ArrayCache: added putDirtyArray() methods
- RendererContext: added dirtyInt/Float array ca
Thanks,
I got it and made clean & build.
Do you want a new webrev concerning added Path2D.trimToSize () methods for
JDK9 ?
PS: I will send you asap the second marlin patch fixing some of your
initial comments (dirty vs zero-filled arrays).
Moreover I postponed my work on Stroker as it is tricky,
Jim,
Thanks for giving news !
> Yes, I'm working on getting it pushed to 9-dev and then getting backport
approval to 8u60, but I've been foiled by not having updated my JDK build
environment for a few months and am almost there. Meanwhile we have
submitted the trim() method for CCC approval and h
Jim & Phil,
Are you ok with the latest webrev?
Laurent
Le 23 avr. 2015 16:25, "Laurent Bourgès" a
écrit :
> Jim,
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.3/
>
> The same copyOf() change would apply to the meth
Jim,
Here is an updated webrev:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.3/
The same copyOf() change would apply to the method that grows the types
> array.
>
Fixed.
> I created https://bugs.openjdk.java.net/browse/JDK-8078464 for this part
> of the fix...
>
Thanks, I added
Jim,
Here is a new webrev to improve the grow algorithm of Path2D needRoom() and
handle properly overflow:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.2/
Changes:
- fixed condition in needRoom() methods to avoid overflow
- use Arrays.copyOf(oldCoords, newSize) in expandCoords() me
o make a new bug and target the existing patch
at it by just removing the new method signature...
>
> ...jim
>
>
> On 4/20/15 11:56 PM, Laurent Bourgès wrote:
>>
>> Jim & phil,
>>
>> The initial objective of my patch concerns the grow algor
Jim & phil,
The initial objective of my patch concerns the grow algorithm to use 1/8th
of the array size instead of the fixed EXPAND_MAX (=500) !
For huge paths, it avoids a lot of growing passes and is a lot faster (see
Path2DGrow test: 2s vs 56s).
However, it wastes more memory (overflow or OO
We'll need
> to do some other internal processes to get approval for that...
>
> ...jim
>
> On 4/10/15 8:07 AM, Laurent Bourgès wrote:
>
>> Jim,
>>
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D_ne
Sorry I forgot mailing lists in CC !
Hi Jim,
Did you start looking at early rejection of segments (clipping) ?
On my side, I looked at the Stroker class and I figured out why it
generates so many segments (4M) for my 800k spiral: mitter join are
generated with many intermediate segments.
I wrot
Le 10 avr. 2015 21:08, "Laurent Bourgès" a
écrit :
> Jim,
>
> Please consider other changes also !
>
> I added the trim method after the discussion. I can remove it if it makes
> you approve the patch quicker.
>
> Laurent
> Le 10 avr. 2015 20:51, &q
Jim,
let's go back to concrete code:
2015-04-04 0:25 GMT+02:00 Jim Graham :
> The patch as it is will make things much better, but it may be worth
> "doing it right" as long as we are revisiting this algorithm and write it
> to deal better with the OOME/integer overflow cases.
>
My patch is ver
as many applications already have their own (custom) solution.
Please read my comments below:
Le 7 avr. 2015 00:38, "Jim Graham" a écrit :
>
> On 4/4/15 3:15 AM, Laurent Bourgès wrote:
>
>> I may look at this implementation to get some idea or maybe I should
>> just optimi
Andrea,
>> Do you have a fast and efficient polygon clipper in geoserver ?
>
>
> We use this one for fast rectangular clipping:
>
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/geometry/jts/GeometryClipper.java
Thanks for the link,
It seems I coul
Andrea,
Great to have your point of view !
Is it public data ?
Is it possible to convert this particular shape file to a MapBench's
serialized command file (not simplified, please) ?
It would be helpful to have concrete but very complex shapes to perform
both renderer benchmarks (marlin, pisces,
Sergey,
2015-04-03 15:16 GMT+02:00 Sergey Bylokhov :
> Hello.
> Is that a problem that with the new code we can get OOM earlier in some
> cases? Should we take care of overflow more carefully now? It seems that
> ArrayList.grow contains similar logic.
>
>
I advocate I did not test with a small he
Jim,
Here is the first webrev:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.0/
I created a test Path2DGrow that also gives some timings:
Without patch:
- Test(Path2D.Double[0]) ---
testAddMoves[100] duration= 21.8489867 ms.
testAddLines[100] duration= 2883.4139689
1 - 100 of 136 matches
Mail list logo
