[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Dear all, I recently profiled my swing application (Aspro2: http://www.jmmc.fr/aspro) using the netbeans profiler (OpenJDK8 / linux x64) and in contrary to Oracle JDK, it consumes a lot of memory in sun.java2D.pisces code as int[] or float[] arrays: - Helpers.widenArray : 25Mb - Rendererinit: 75

[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Dear all, First I joined recently the openJDK contributors, and I plan to fix java2D pisces code in my spare time. I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an application to prepare astronomical observations at VLTI / CHARA and is very used in our community (200 users):

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

there is some hotspot magic involved to recognise and intrinsify this method, since the source code looks like a plain old for loop. -phil. On 3/26/2013 4:00 AM, Laurent Bourgès wrote: Dear all, First I joined recently the openJDK contributors, and I plan to fix java2D pisces code in my spare

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Andrea, It could be very interesting if you could provide some concrete example about your map server: typical image height / width, shape complexity (number, size, path sizes ...). Ideally if you could write a test class (sample) computing a single image it would be very helpful for me to

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage Dasher clipping problem

the dashes and widened paths for parts that are outside the clip, at least we don't spend time rasterizing them? I should check if the Renderer really skips (edges / tiles) that are out of the clipping area. (ScanLineIterator ...) Thanks again, Happy easter, Laurent On 3/28/2013 8:40 AM, Laurent

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

in order to tune Pisces automatically depending on the user work load. Regards, Laurent On 3/29/2013 6:53 AM, Laurent Bourgès wrote: Phil, I agree it is a complex issue to improve memory usage while maintaining performance at the JDK level: applications can use java2d pisces in very

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

) has to be smart (auto - tune) - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste) 2013/3/30 Andrea Aime andrea.a...@geo-solutions.it On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès bourges.laur...@gmail.com wrote: Andrea, It could be very interesting if you

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Thanks for your valueable feedback! Here is the current status of my patch alpha version: http://jmmc.fr/~bourgesl/share/java2d-pisces/ There is still a lot to be done: clean-up, stats, pisces class instance recycling (renderer, stroker ...) and of course sizing correctly initial arrays

[OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Dear java2d members, I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency memory usage: - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile() - excessive memory usage

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Dear all, Here is my first pisces (beta) patch (webrev): http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ I succeed in fixing memory usage by having only 1 pisces instance (Renderer, stroker, iterator ...) per RendererContext (GC friendly). Impressive results between small and large

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Dear Jim, I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated ! The main question is: how to know how GC / hotspot deals with such small allocations ? Is there any JVM flag to enable to see real allocations as does jmap -histo. Quick questions -

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 2013/4/10 Andrea Aime andrea.a...@geo-solutions.it On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourgès bourges.laur...@gmail.com wrote: Also, this should be tested on multiple platforms, preferably Linux

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Dear Jim, 2013/4/9 Jim Graham james.gra...@oracle.com The allocations will always show up on a heap profiler, I don't know of any way of having them not show up if they are stack allocated, but I don't think that stack allocation is the issue here - small allocations come out of a fast

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

AM, Laurent Bourgès wrote: Dear Jim, 2013/4/9 Jim Graham james.gra...@oracle.com The allocations will always show up on a heap profiler, I don't know of any way of having them not show up if they are stack allocated, but I don't think that stack allocation is the issue here - small

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Sergey, I am not an expert here but just my 50 cents. This optimization shall take place only if it is really hotspot. But if it is a really hotspot - probably it would be better to remove these array/object allocation at all and use plane bytes? Java2D calls AAShapePipe for each shape

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Jim and Sergey, 1/ Here are few benchmarks (based on mapBench again) running several modified versions of AAShapePipe: http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ - ref: 1 threads and 20 loops per thread, time: 3742 ms 2 threads and 20 loops per thread, time: 4756 ms 4 threads and 20

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

timing / comparison between bench runs. Regards, Laurent 2013/4/11 Laurent Bourgès bourges.laur...@gmail.com Jim and Sergey, 1/ Here are few benchmarks (based on mapBench again) running several modified versions of AAShapePipe: http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ - ref: 1

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Hi clemens Le 17 avr. 2013 23:16, Clemens Eisserer linuxhi...@gmail.com a écrit : Hi Laurent, thanks for having some interest for my efforts ! As I got almost no feedback, I felt quite disappointed and was thinking that improving pisces was not important ... Glad to see work is ongoing to

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, First, here are both updated webrev and benchmark results: - results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log - webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/ Note: the webrev is partially cleaner - work still in progress ! Changes made: - optimized

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, Sorry for the delay: I was busy on reworking the tile generation to cache only a single line of tiles: it allows me to have ROWAARLE[32][] and touchedTile a 1d array. I simply do the rendering when nextTile() detects a tile line end ! Now it is working and the thread local cache is

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, here is the latest webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-3/ I tried to revert some syntax mistakes (indentation, moved constants + cleanup) : code cleanup is still in progress; so please don't have a frawny face while looking at the code! I fixed also Ductus and Jules

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, thanks for this long explanations and I agree you approach using semi-open intervals. I have the feeling that pisces was not so accurate implementing it. My comments in the text: I have few questions regarding renderer edge handling and float ceil calls: I have a personal philosophy

Re: [OpenJDK 2D-Dev] YourKit Java Profiler Open Source License Request

Dear Dalibor, Donald and java2d members, I am currently working hard to improve performances of the pisces java2d renderering engine. To help me improving cpu hotspots, I need an efficient java profiler (lower overhead than netbeans profiler). I *personally* requested this morning an open

Re: [OpenJDK 2D-Dev] YourKit Java Profiler Open Source License Request

for spotting it, Laurent 2013/5/6 Laurent Bourgès bourges.laur...@gmail.com Andrew, I want to have good metrics related to java code (not native) so I need a java profiler. maybe dtrace could be another candidate but I don't know how to use it on my linux 64 machine. Laurent I am currently

Re: [OpenJDK 2D-Dev] YourKit Java Profiler Open Source License Request

Terms of Use. - Don On 06/05/2013 5:46 AM, Laurent Bourgès wrote: Dear Dalibor, Donald and java2d members, I am currently working hard to improve performances of the pisces java2d renderering engine. To help me improving cpu hotspots, I need an efficient java profiler (lower overhead

Re: [OpenJDK 2D-Dev] YourKit Java Profiler Open Source License Request

TouchDown (www.nitrodesk.com) -Original Message- From: Laurent Bourgès [bourges.laur...@gmail.com] Received: Monday, 06 May 2013, 22:07 To: Donald Smith [donald.sm...@oracle.com] CC: disc...@openjdk.java.net [disc...@openjdk.java.net]; 2d-dev@openjdk.java.net [2d-dev@openjdk.java.net

Re: [OpenJDK 2D-Dev] YourKit Java Profiler Open Source License Request

opcontrol --shutdown * Thanks for your support, Laurent 2013/5/6 Andrew Haley a...@redhat.com On 05/06/2013 04:12 PM, Laurent Bourgès wrote: Could you give advices on how to use it with custom OpenJDK builds, andrew IME it Just Works. The oprofile shipped with Linux distros has everything you

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Andrea, Jim and java2d members, I am going back to my work on java2d pisces improvements (scanline rendering optimization). Two comments: - hotspot takes some time to optimize the very large Renderer.endRendering() and ScalineIterator.next() methods: probably because these methods represents too

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

to integers) Laurent 2013/5/29 Andrea Aime andrea.a...@geo-solutions.it On Wed, May 29, 2013 at 11:01 AM, Laurent Bourgès bourges.laur...@gmail.com wrote: Finally I propose to focus on optimizing these 2 algorithms (methods) as it represents 55% of cpu time: - optimize / modify algorithms

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Dear Java2D members, Sorry to ask but does anybody care about improving java2D rendering (quality, performance) ? I sent several emails for one month and nobody answered. Should I consider that there is no interest and give up ? I am still waiting for feedback and support before going on

Re: [OpenJDK 2D-Dev] New GeoServer benchmarks with Laurent's l4 webrev

Andrea, thanks for your time testing my patch in a real benchmark ! I think that the ratio of pisces rendering / request processing is very low (few percents) that's why the performance gains between L1 and L4 are so little. How many cpu cores have your machine ? As you can see L1 provides

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, I think I found the source of the 'poor' quality of line rendering: the alpha coverage is only computed for the 2 sub pixels (x0, x1) at the current x-coordinate of an edge ie it does not take into account the span of a line having a very flat slope: for (i = 0, sum = 0,

Re: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up Pisces

Andrea, I made some progress since webrev 4 (may 2013) but mainly stopped working on it due to lack of time and there is apparently no way (no bug id, no feedback) to integrate my efforts into JDK 8. I can try soon to produce a new patch (5) including my last changes (close to initial code, less

[OpenJDK 2D-Dev] Custom rendering engines in jk9

Phil, In the following bug, you propose to remove the ServiceLoader in the RenderingEngine class: https://bugs.openjdk.java.net/browse/JDK-8038875 For now the jdk has only ductus and pisces engines but I am working on marlin which is an improved pisces: https://github.com/bourgesl/marlin-renderer

Re: [OpenJDK 2D-Dev] Custom rendering engines in jk9

Phil, Le 1 avr. 2014 23:42, Phil Race philip.r...@oracle.com a écrit : Hi Laurent, Yes, we'll keep the system property (at least for JDK 9) that should support Class.forName usage. In the JDK I expect well just look for ductus by name then pisces, all hard-coded, but the system property

[OpenJDK 2D-Dev] Merging marlin pisces rendering engines

Phil, Do you some guys who could help me merging marlin with pisces in jdk9 ? I need help creating small sequential patches as webrevs and also reviewers. I made the MapDisplay tool to perform regression tests vs pisces: https://github.com/bourgesl/mapbench FYI I released marlin 0.4.4 which is

Re: [OpenJDK 2D-Dev] Graphics2D.fill(Shape) operation always fails with a custom Composite

pressure on me to push changes ASAP ... -- Laurent Bourgès

Re: [OpenJDK 2D-Dev] Merging marlin pisces rendering engines

on github and binary releases are available (ready to use on both Oracle Open Jdk) It was tested on windows, macos linux 64 (server vm) with jdk 7 8. You can already use it without waiting for jdk9 ! Best regards, Laurent Le 30 mai 2014 18:38, Laurent Bourgès bourges.laur...@gmail.com a écrit

[OpenJDK 2D-Dev] MaskFill incorrect gamma correction (sRGB != linear RGB)

and the jvm must be started with -Xbootclasspath/p:path/patch.jar Looking forward your comments, Laurent Bourgès /* * Copyright (c) 1997, 2002, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can

Re: [OpenJDK 2D-Dev] MaskFill incorrect gamma correction (sRGB != linear RGB)

Hi, Here are questions about the java2d pipeline to understand how colors are handled as pixel values (conversions): - BufferedImage use by default the sRGB colorspace (non linear) so its raster data (RGBA) are encoded as int values (sRGB). What parts of the java2d pipeline handle color blending

Re: [OpenJDK 2D-Dev] MaskFill incorrect gamma correction (sRGB != linear RGB)

linear components like scRGB: http://en.wikipedia.org/wiki/ScRGB Anybody has other ideas ? opinions ? Regards, Laurent Bourgès

[OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Dear all, Following our discussions during last FOSDEM, could you tell me how to proceed in improving the java2d rasterizer (JEP or patches) ? Who could help me on that topic (patch, review, test...) ? The aim consists in improving OpenJDK's pisces rendering engine to achieve better performance

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Phil, Two more things regarding the test 1. It was pointed out that you are using GPL+CP .. tests just use GPL You mean I must fix the test file header ? 2. There's no @bug tag the test. In fact there's no bug ID here at all :-) A bug ID is needed in order to push. You have a JBS account

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Jim, Here is my first official webrev (vs graphics-rasterizer forest) concerning Path2D copy constructors: http://cr.openjdk.java.net/~lbourges/webrev_Path2D_0/ this is a simple Path2D patch to trim arrays (numTypes float/double Coords) in copy constructors (Path2D.Float and Path2D.Double

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Phil, Thanks for your feedback ! 2015-03-06 20:06 GMT+01:00 Phil Race philip.r...@oracle.com: Hi, you placed the test in the java.awt.geom package. 25 package java.awt.geom; and are accessing internals of that package. In jigsaw/modular mode that won't even compile. Ok it is

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations

Jim, Ok, I will totally rewrite the Path2D test soon. I was busy on marlin optimizing its merge sort variant based on my mapbench's array data (stats...). I will publish soon a new release with an up-to-date report between pisces, marlin ductus. Cheers, Laurent

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Dear all, I am glad to announce that I submitted first Marlin webrevs and a new thread has started on the graphics-rasterizer mailing list: http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/2015-March/73.html I think it is time to stop this thread on the java2d mailing list.

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Sorry, I forgot to mention I made a performance summary: http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/2015-March/77.html Here is the performance summary: http://cr.openjdk.java.net/~lbourges/marlin/report/perf_summary.htm *Threads* *4* *1* *2* *4* *Renderer* *Test count*

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations

Dear Jim, Here is the new webrev: http://cr.openjdk.java.net/~lbourges/path2D/Path2D.3/ Looks great. Thanks, I hope this patch is ready to go in. - A couple of methods have /** even though the comment is just informational to the programmer and not representing an API. It looks like /** is

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations

Jim, Test program, line 490 - MOVETO has 2 coordinates associated with it. Well spotted: I did it too quickly, sorry. Test program, line 492 - perhaps we should throw an exception on default since it indicates a problem with the iterator Ok. Other than that, it looks good... Thanks, I

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations

Jim, Test program, line 490 - MOVETO has 2 coordinates associated with it. Well spotted: I did it too quickly, sorry. Test program, line 492 - perhaps we should throw an exception on default since it indicates a problem with the iterator Ok. Here is the new webrev:

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Hi again, Ok, I have to submit a webrev. There is two marlin variants: - marlin 0.4.5 - marlin 0.5.5 using Unsafe for array allocation and random access to store edge data as struct [float + int] Note: marlin 0.5.5 is 10% faster in my benchmarks. What variant do you prefer ? If

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Phil, I asked several times how to contribute back marlin to openjdk since may 2014... as pisces patches ? or as an alternative renderer ? As I've asked for a long time, a webrev you create against openJDK is what I'd like to see. I can't assess what a delta it would be against pisces

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Jim, Ah, wait, those constructors do copy the arrays without having to iterate the segments and grow the arrays, but they don't trim them. I'm trying to remember if there was a specific reason that we decided not to trim the arrays in those constructors, but the only advantage I can think of is

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Jim, Thanks for your feedback and sorry for your wasted time. I will be more patient ... before sending webrevs. Laurent

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Jim, I made a Path2D patch but I sent the webrev by email. Did you got it ? Could you review it ? I got a size limit issue: Your message to 2d-dev awaits moderator approval ! Looking forward having an openjdk id ro push my webrev to cr.openjdk.net ! Regards, Laurent Le 25 févr. 2015 02:06, Jim

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Phil, here is my first attempt to produce a webrev for the marlin renderer (derived from 0.5.5 Unsafe) against graphics-rasterizer/jdk9/ http://hg.openjdk.java.net/graphics-rasterizer/jdk9/ http://jmmc.fr/~bourgesl/share/graphics-rasterizer/webrev-1/ Of course, it is a big patch that you can

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations

Jim, Here is a new Path2d patch: http://cr.openjdk.java.net/~lbourges/path2D/Path2D.2/ Changes: - Fix ArrayIndexOutOfBounds in ptCrossing / rectCrossing when coords array is zero-sized (0 capacity constructor): bug present in jdk8 - new tests: Path2dEmpty to test this bug Path2dCopyConstructor

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Jim, 2015-03-05 23:50 GMT+01:00 Jim Graham james.gra...@oracle.com: Some progress! It looks like Laurent is now an official committer to the graphics-rasterizer project! http://openjdk.java.net/census#lbourges Yes it is great ! Have you gotten access to

Re: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

Phil, Here is a new webrev: http://cr.openjdk.java.net/~lbourges/webrev_Path2D_1/ See my comments below: you placed the test in the java.awt.geom package. 25 package java.awt.geom; and are accessing internals of that package. In jigsaw/modular mode that won't even compile. Ok it is

Re: [OpenJDK 2D-Dev] RFR: 8075942: ArrayIndexOutOfBoundsException in sun.java2d.pisces.Dasher.goTo

Hi Phil, I can fix that bug in pisces as I already did it in Marlin. You can have a look to Marlin Dasher as your proposed change look very similar to what I did. Laurent Le 2 avr. 2015 00:58, Phil Race philip.r...@oracle.com a écrit : https://bugs.openjdk.java.net/browse/JDK-8075942

Re: [OpenJDK 2D-Dev] RFR: 8075942: ArrayIndexOutOfBoundsException in sun.java2d.pisces.Dasher.goTo

Phil, I did not see you provided a webrev: looks good. I will run the test against marlin and check if it works and also if it test exceeding its initial array capacity. Thanks and sorry for the noise, Laurent Le 2 avr. 2015 07:17, Laurent Bourgès bourges.laur...@gmail.com a écrit : Hi Phil

Re: [OpenJDK 2D-Dev] Path2d needRoom very slow for huge paths

I can understand to promote the 99% use case (small path) but the performance penalty is too important to me for large paths Let's have jim's point of view as he knows the complete story... Laurent Le 2 avr. 2015 19:33, Phil Race philip.r...@oracle.com a écrit : I should have paid more

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

to 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 algorithm to use 1/8th of the array size instead of the fixed

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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 the

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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()

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Jim Phil, Are you ok with the latest webrev? Laurent Le 23 avr. 2015 16:25, Laurent Bourgès bourges.laur...@gmail.com 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 method that grows

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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

Re: [OpenJDK 2D-Dev] RFR: 8u backport of 8076419: Path2D copy constructors and clone method propagate size of arrays from source path

Phil, It seems OK for me but I am not an official reviewer, just the patch author. Laurent Le 15 mai 2015 22:02, Phil Race philip.r...@oracle.com a écrit : I have prepared a direct 8u-dev backport of the JDK 9 fix for https://bugs.openjdk.java.net/browse/JDK-8076419

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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_needRoom.1/ Changes: - needRoom() applies your pseudo-code; see

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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 could try

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

already have their own (custom) solution. Please read my comments below: Le 7 avr. 2015 00:38, Jim Graham james.gra...@oracle.com 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 optimize openjdk's Area class that has

Re: [OpenJDK 2D-Dev] Path2d needRoom very slow for huge paths

Hi again, I quickly tested the proposed solution: void needRoom(boolean needMove, int newCoords) { if (needMove numTypes == 0) { throw new IllegalPathStateException(missing initial moveto + in path

Re: [OpenJDK 2D-Dev] Path2d needRoom very slow for huge paths

Phil, Just a short comment: pisces was originally written for the ME environment so I suspect that it was very conservative in allocating new heap space. That clearly does not matter so much on desktop so the proportional approach rather than the fixed size approach seems better. 1/8th seems

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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,

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

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=

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Sergey, 2015-04-03 15:16 GMT+02:00 Sergey Bylokhov sergey.bylok...@oracle.com: 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

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Le 10 avr. 2015 21:08, Laurent Bourgès bourges.laur...@gmail.com 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, Jim Graham james.gra...@oracle.com

Re: [OpenJDK 2D-Dev] RFR: 8u backport of 8078464 : Path2D storage growth algorithms should be less linear

Phil, It is ok for me. Laurent

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

PM, Phil Race wrote: >> >> Looks good. >> >> -phil. >> >> On 12/04/2015 02:55 PM, Jim Graham wrote: >>> >>> Looks good to me. Are jigsaw issues good Phil? >>> >>> ...jim >>> >>> On 12/3/1

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

Jim, I think this patch fixes properly the segfault issue on sparc as confirmed by Tobias. Le 8 déc. 2015 02:13, "Jim Graham" a écrit : > > Do we make sure that the subpixel coords don't overflow an integer somewhere? I will create a new bug related to this specific

Re: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging

ld remain confidential but interesting to keep in the code (disabled by default). The JMH perfasm profiler is better as it provides more accurate timings and lower overhead! Laurent > On 12/5/15 8:54 AM, Laurent Bourgès wrote: >> >> Phil & Jim, >> >> Here is the updat

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

Jim, I created the following bug to handle properly coordinate overflow: https://bugs.openjdk.java.net/browse/JDK-8144938 Cheers, Laurent 2015-12-08 9:11 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Jim, > > I think this patch fixes properly the segfault issue on spa

Re: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of deleted internal API

Phil, No problem. I mentioned some time ago that this tracing method is somewhat not really useful anymore. I will take care of the clean up afterwards. Laurent Le 2 déc. 2015 19:41, "Phil Race" a écrit : > https://bugs.openjdk.java.net/browse/JDK-8144526 > >

[OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins

vide a simple test class that reproduces the issue. Regards, Laurent Bourgès

Re: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal

t should never happen) ! If you want, I could add few assertions. > Stroker.java line 1276 - "numCurves >= curveTypes.length" would also > work...? > Fixed. > > In the test cases that expect an exception, if no exception is thrown then > you pass the test. I

[OpenJDK 2D-Dev] RFR :

Hi, Please review this webrev fixing the long-standing bug in imageio PNGImageWriter to support compression levels: bug: https://bugs.openjdk.java.net/browse/JDK-6488522 webrev: http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.0/ Changes: - default Deflater level changed from 9 (best)

[OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting compression level and iDAT chunk maximum size

Hi, Please review this webrev fixing the long-standing bug in imageio PNGImageWriter to support compression levels: bug: https://bugs.openjdk.java.net/browse/JDK-6488522 webrev: http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.0/ Changes: - default Deflater level changed from 9 (best)

Re: [OpenJDK 2D-Dev] RFR :

Sorry I forgot to fill the mail subject ! I have sent another email. Laurent

Re: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting compression level and iDAT chunk maximum size

Hi Sergey, Thanks for your comments, did you review the PNGImageWriter changes too ? 2015-12-09 14:19 GMT+01:00 Sergey Bylokhov : > Hi, Laurent. > Should the test check the resulted image in the file? At least it can > check that the CompressionMode is not ignored

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

el coords don't overflow an integer >>> somewhere? >>> >>> ...jim >>> >>> On 12/7/15 1:52 PM, Laurent Bourgès wrote: >>>> >>>> Moreover, it is concretely impossible as subpixel coords implies the >>>

Re: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins

s > > 1: > > // check round off errors producing cos(ext) > 1 and a NaN below > // cos(ext) == 1 implies colinear segments and an empty join anyway > > ...jim > > > On 12/4/15 8:33 AM, Laurent Bourgès wrote: > >> Hi, >> >> Please

Re: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats

Phil, 2 reviewers approved, so please push it for me ! Laurent 2015-12-05 0:07 GMT+01:00 Jim Graham <james.gra...@oracle.com>: > Looks good... > > ...jim > > > On 12/3/15 1:37 PM, Laurent Bourgès wrote: > >> https://bugs.openjdk.java.ne

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

>> ...jim >> >> On 12/3/15 12:58 PM, Laurent Bourgès wrote: >> >>> Phil, >>> >>> If you were to run this on a jigsaw EA build it would fail due to >>> accessing >>> sun.java2d.pipe.RenderingEngine. I

Re: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging

Phil & Jim, Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/ Changes: - isEnableLogs() renamed to isLoggingEnabled(); I used the convention "is" even if it is not english ! - restored doMonitors to false (as it reduces the bytecode count for inlining)

[OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging

MarlinProperties.isEnableLogs() and restore potential doMonitors / doChecks flags - MarlinProperties: added isEnableLogs() - MarlinUtils: use PlatformLogger instead of Logger and removed getCallerInfos() - RendererContext: remove all MarlinUtils.getCallerInfos() Best regards, Laurent Bourgès

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

Phil, If you were to run this on a jigsaw EA build it would fail due to accessing > sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but jigsaw > is coming ... > You're right, sorry ! Here is a new webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-816.1/ Changes: -

[OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats

https://bugs.openjdk.java.net/browse/JDK-8144630 Please review this simple webrev that fixes the Thread creation in RendererStats: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/ Regards, Laurent Bourgès

  1   2   3   >