Hi Anton,
On 1/31/14 6:37 AM, Anton V. Tarasov wrote:
My understanding is that, unless the fix is absolutely irrelevant (whic
I hope it isn't), we should integrate it into 9/8u20 to support
SwingNode in its current implementation on Retina displays.
What do you think?
I agree with this sentim
n the presence of various
DPI factors.
...jim
On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
On 1/22/2014 6:40 AM, Jim Graham wrote:
Hi Alexander,
Before we get too far down the road on this API, I think we understand
the way in which MacOS processes multi-resolution i
Hi Anton,
In CPlatformLWWindow.java, why does it have to search for the right
device when it was created with/from a Window object that should already
know the right device?
SG2D, line 2114 - I think TRANSFORM_SCALE allows negative scale factors
so I think you need a little more protection f
On 2/10/14 6:11 AM, Anton V. Tarasov wrote:
On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
In SG2D, the drawHiDPIImage, for instance, makes a call to
op.filter(img, null); where the img is expected to return its layout
size. That's why I still prefer to use the setReturnLayoutSize
"switcher", in o
...jim
On 2/10/14 3:37 PM, Jim Graham wrote:
On 2/10/14 6:11 AM, Anton V. Tarasov wrote:
On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
In SG2D, the drawHiDPIImage, for instance, makes a call to
op.filter(img, null); where the img is expected to return its layout
size. That&#
stage...
...jim
On 2/11/14 10:10 AM, Anton V. Tarasov wrote:
Hi Jim,
On 2/11/14 4:12 AM, Jim Graham wrote:
Just out of curiosity, on a Mac there is support for @2x images where
they get loaded and used (at half scale to preserve layout size)
automatically for you. In that respect, the added resol
On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
On 2/8/2014 4:19 AM, Jim Graham wrote:
The primary thing that I was concerned about was the presence of
integers in the API when Windows uses non-integer multiples
It would make sense to pass real numbers to the
getResolutionVariant
On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
Hi Jim,
Please, look at the update:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
Here I'm correcting the rect after the transform in SG2D:
2123 // In case of negative scale transform, reflect the rect
coords.
2124 if (w < 0
.02.2014 2:52, Jim Graham wrote:
On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
Hi Jim,
Please, look at the update:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
Here I'm correcting the rect after the transform in SG2D:
2123 // In case of negative scale transform, reflect
Yes, approved.
...jim
On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
Jim, so this is ready for a push then.
Thanks!
Anton.
On 15.02.2014 5:01, Jim Graham wrote:
I don't need to see an update for that. I didn't read the entire
webrev, but I looked at this one piece o
...jim
Thanks,
Alexandr.
On 2/13/2014 4:42 AM, Jim Graham wrote:
On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
On 2/8/2014 4:19 AM, Jim Graham wrote:
The primary thing that I was concerned about was the presence of
integers in the API when Windows uses non-integer
Hi Andrew,
It looks like you are covering the case of the existing loops being
Solid and we switch to XOR so you get new loops. What about the case
where we used to be XOR and then we switch to Solid and the loops might
be stale, but in the other way (i.e. XOR when we want Solid rather than
updated fix:
http://cr.openjdk.java.net/~bae/8036022/9/webrev.01/
Thanks,
Andrew
On 3/14/2014 4:36 AM, Jim Graham wrote:
Hi Andrew,
It looks like you are covering the case of the existing loops being
Solid and we switch to XOR so you get new loops. What about the case
where we used to be XOR and t
http://cr.openjdk.java.net/~bae/8036022/9/webrev.01/
Thanks,
Andrew
On 3/14/2014 4:36 AM, Jim Graham wrote:
Hi Andrew,
It looks like you are covering the case of the existing loops being
Solid and we switch to XOR so you get new loops. What about the case
where we used to be XOR and then we s
image.getHeight(null)) {
return image;
}
}
return this;
}
}
--
Thanks,
Alexandr.
On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
On 2/22/2014 3:54 AM, Jim Graham wrote:
Hi Alexandr,
On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
Hi Jim,
;= image.getWidth(null) && height <=
image.getHeight(null)) {
return image;
}
}
return this;
}
}
--
Thanks,
Alexandr.
On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
On 2/22/2014 3:54 AM, Jim Graham wrote:
Hi Alexand
aving to custom wrap
every image?
So the method looks like: getResolutionVariant(float logicalDPIX,
float logicalDPIY, float destImageWidth, float destImageHeight)
See others comments inline...
On 3/21/2014 3:50 AM, Jim Graham wrote:
Hi Alexandr,
SG2D leaks its internal t
Hi Anton,
A lot of those tests seem out of whack in that they test related
conditions, but not the exact condition itself. What we really want is
for every index of the form:
offset + y * scanlineStride + x + {0 -> numcomponents-1} => [0,
buf.length-1]
to be in the array for all valid x,y
o create a custom multi-resolution image. For example:
On 3/22/2014 3:57 AM, Jim Graham wrote:
Your code example below can be expressed as an implementation of the
single-method, lambda-compatible interface that expresses just the
getRV() method. They could easily do:
final Image
The new code in SwingUtilities2 looks good to me, so I'll approve that
file. I'll leave the code in the rest of the files to Petr...
...jim
On 4/4/14 6:37 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
The problem became visible, when we draw a bor
The fix looks good - approved.
It might be worth noting in the comment that the returned image will be
a single use image and so acceleration caching wouldn't help and just
add overhead compared to rendering it directly from the sw surface. Or
add a single-line comment on the new call to set
Hi Sergey,
That's a really large "worst spread" on the first and 3rd set of
benchmark results. Was the machine quiet during the benchmark run?
Since the variance is larger than the performance gain in some cases it
might be worth getting another set of runs with a lower variance.
Also, the
Some of the other calls are followed by resetting it to 0, but not all
(notably in that same file line 335 sets it to a potentially non-zero
value and does not reset it).
Actually, I just noticed that this one is using PACK_SKIP, but the other
cases are using UNPACK_SKIP. Still, between the t
Given how vectors of curves are constructed, either they are the output
of a previous operation, in which case you need enough curves/edges to
enclose an area and the count must be 0 or >=2, or they are the result
of ingesting a Shape. Looking at the code that ingests a Shape in
Area.pathToCur
No, I think Henry got it right and it should have only been intending to
treat its return value as Vector...
...jim
On 4/7/14 4:13 PM, Joe Darcy wrote:
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lin
Perhaps a simpler fix would be to return an empty Curve list there since
you can't have an enclosed area with fewer than 2 edges (even if it is a
curve, the segments are already broken up into monotonically
increasing/decreasing sections so no single curve segment can double
back on itself and
Shouldn't Order2, lines 50,77 be ""?
Ditto for Order3, lines 56,108?
I don't think we ever use these methods with any other type of Vector,
but I guess I can see that the choice you made might be a more general
choice.
This concludes my review of the geom files per Phil's request. They
look
The benchmark spreads look much better and the code looks good, but I
worry that we are being inconsistent in whether or not we set the SKIP_
values. This function sets them back to 0 when done, but can we assume
that about all code that uses these methods?
...jim
On
ities?
...jim
On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
On 4/3/2014 2:23 AM, Jim Graham wrote:
Hi Alexandr,
The back and forth is getting confusing here, so I thought I'd try to
summarize and start fresh(ish):
1. We need to support @2x internally for MacOS compatibility (done).
2. We wi
Hi Sergey,
I think the bug is in the readObject routine. It sets the initial size
of the arrays based on if the number of segments/coords is "< 0" and it
sets them to INIT_SIZE or INIT_SIZE*2 accordingly. Those tests should
be "< INIT_SIZE(*2)"...
...jim
On 4/30/14
If they specify something on the command line, and that doesn't exist,
then we end up with Pisces even if Ductus is available. Is that
intentional?
Also, why the switch from "getProperty(, default)" to the basic
getProperty() and manually applying the default?
...jim
What about loading native libraries from the 2 engines? Or are those
each individually protected by their own doPrivileged?
...jim
On 5/7/14 2:57 PM, Phil Race wrote:
I did away with the doPrivileged and it seems fine ...
http://cr.openjdk.java.net/~prr/8038875.1/
-ph
Looks good...
...jim
On 5/8/14 11:32 AM, Phil Race wrote:
See http://cr.openjdk.java.net/~prr/8038875.2
-phil.
On 05/07/2014 08:21 PM, Phil Race wrote:
On 5/7/14 5:18 PM, Jim Graham wrote:
If they specify something on the command line, and that doesn't
exist, then we e
Hi Sergey,
It looks fine to me.
If you are having trouble getting consistent results due to
multi-tasking on the machines, it may make sense to look at the "best"
time for each configuration even though I think in general using the
default averaging with more a quieter testing environment is
the current
segment, but it doesn't enforce a minimum of INIT_SIZE).
The fix looks fine...
...jim
On 5/5/14 6:30 AM, Sergey Bylokhov wrote:
Hi, Jim.
On 01.05.2014 4:44, Jim Graham wrote:
Hi Sergey,
I think the bug is in the readObject routine. It sets the initial
Hi Henry,
I'm going through unread emails and wasn't sure if I responded to this
before. Approved...
...jim
On 4/25/14 11:12 AM, Henry Jen wrote:
Thanks for the reviw.
On 04/23/2014 02:37 PM, Jim Graham wrote:
Shouldn't Order2, lines 50,77 be "
The only intention was that we be able to compare against older runtimes
when needed. We could ask whether we care about how we currently
compare against 1.2 any more...? If we're really that curious, we can
either change the target and compile with an older compiler, or find an
older version
ns that
benchmark requires at least jdk1.5 to compile.
- I found mismatch between ant/make about debug information. fixed
- the fix for 8005402 did not properly update makefiles for images. fixed
- dest was changed to dist, because this is default location of
J2DBench.jar.
On 07.08.2014 23:55
lines...?
...jim
On 8/12/14 8:32 AM, Sergey Bylokhov wrote:
On 12.08.2014 1:34, Jim Graham wrote:
Hi Sergey,
Is the -g:none the result of #2 below?
This was changed to align with in build
xml(typo was fixed as well).
Also, if I read the email trail correctly then
ergey Bylokhov wrote:
On 12.08.2014 1:34, Jim Graham wrote:
Hi Sergey,
Is the -g:none the result of #2 below?
This was changed to align with in build
xml(typo was fixed as well).
Also, if I read the email trail correctly then source/target=1.6 is
only there because JDK 9 compiler doesn't
...jim
On 8/12/14 8:32 AM, Sergey Bylokhov wrote:
On 12.08.2014 1:34, Jim Graham wrote:
Hi Sergey,
Is the -g:none the result of #2 below?
This was changed to align with in build
xml(typo was fixed as well).
Also, if I read the email trail correctly then source/ta
Hi Laurent,
Java2D has color correction code in it, but it is only really hooked up
to the specific color correction classes so it pretty much has to be
manually invoked. The rendering pipeline usually punts on issues like
color space other than if you specify an alternate color space for a
Hi Sergey,
In the test case you call new BufferedImage() with a Transparency
constant which is essentially a random number to determine the type of
BufferedImage since it is expecting its own values. You get lucky with
the value of the integer as it turns out, but the test case really
should
The fix looks fine. Isn't there a timeout you can set on the unit test
rather than rolling your own inside the test? Also, even if you
interrupt the test, if the failure mode is an infinite loop in native
code then the VM you are running in is probably not going to be happy.
That only happens
clude othervm overhead and
avoid/minimise spurious failures
See http://cr.openjdk.java.net/~prr/8028539.1/
-phil.
On 10/27/2014 2:10 PM, Jim Graham wrote:
The fix looks fine. Isn't there a timeout you can set on the unit
test rather than rolling your own inside the test? Also, even if you
probably fail if it
can't complete in a couple of iterations...
...jim
On 10/28/14 10:28 AM, Phil Race wrote:
On 10/28/2014 5:29 AM, Sergey Bylokhov wrote:
Hi, Jim.
Thanks for review!
On 27.10.2014 21:12, Jim Graham wrote:
In the test case you call new BufferedIm
That looks good. Approved...
...jim
On 10/29/2014 7:33 AM, Sergey Bylokhov wrote:
Hi, Jim.
The new version:
http://cr.openjdk.java.net/~serb/8062164/webrev.03
On 28.10.2014 22:00, Jim Graham wrote:
I wasn't aware that jtreg had a default timeout, but 2 minutes is rather long.
Hi Sergey,
Please don't use "union" to build up a region. There are methods for
building regions that are very efficient and the "union" operation is
meant to be used for occasional operations on 2 already established
regions, not for repeated iterative operations in building up a single
reg
On 11/10/14 12:03 PM, Sergey Bylokhov wrote:
Note that I plan to improve generation of the clip region of this method
later.
Ah, I missed this. It should be fairly easy to write a tight loop in
Region to fill in a spans buffer. I'm not sure it needs to be pushed
off. It would either be fil
On 11/10/14 2:52 PM, Sergey Bylokhov wrote:
Hi, Jim.
To simply fill a span in the Region, I'll need to open Region.appendSpan()
method,
but I do not want to do it.
No, that method should remain private. All region objects should be
fully constructed at all times when in the hands of calli
sion of the fix:
http://cr.openjdk.java.net/~serb/8059942/webrev.16
The new method in Region class was added.
On 11.11.2014 5:43, Jim Graham wrote:
On 11/10/14 2:52 PM, Sergey Bylokhov wrote:
Hi, Jim.
To simply fill a span in the Region, I'll need to open
Region.appendSpan() method,
but I
On 11/13/14 2:56 PM, Sergey Bylokhov wrote:
Hi, Jim
Please revert all "iff => if" changes in Region - those are not typos.
ok
Hand-coding would require adding a bunch of code for clipping, though
it might be faster still by avoiding all of the "are we on a new row?"
testing in appendSpan/en
On 11/13/14 5:45 PM, Sergey Bylokhov wrote:
Moreover this code have a big impact(hundreds percents) on the performance
of drawing, I consider we should return region from the TransformHelper
directly in the future(or we should change format of edges array to the
bands array format). I do not se
Hi Sergey,
On 11/14/14 6:40 AM, Sergey Bylokhov wrote:
Hi, Jim.
Please review an updated version of the fix:
http://cr.openjdk.java.net/~serb/8059942/webrev.17
Two notes:
- one additional byte still is added to the bands, since I am still checking
the code where we use endIndex-1/endIndex+1/e
On 11/14/14 5:36 PM, Sergey Bylokhov wrote:
- james.gra...@oracle.com wrote:
One thing to consider, though, is that this code is only used in some
rare cases - either that we don't have a direct native loop for the TH
native code to use directly, or that it is a custom composite.
or bicu
I see what you are saying, if we get in here with a native destination
surface at all then we aren't likely to find a native maskblit.
I don't think bicubic and BG operations are that common, though. And I
don't think they are common enough to warrant creating a new pathway to
potentially cre
:50, Jim Graham wrote:
Hi Sergey,
On 11/14/14 6:40 AM, Sergey Bylokhov wrote:
Hi, Jim.
Please review an updated version of the fix:
http://cr.openjdk.java.net/~serb/8059942/webrev.17
Two notes:
- one additional byte still is added to the bands, since I am still
checking the code where we use
Stop using them and replace them with new package private methods and a
cross-package accessor (similar to the SurfaceManager.ImageAccessor
pattern)? What are the technical constraints preventing this?
I think the getPeer() method used to be used by AWT applications to tell
if an app was on t
Looks good...
...jim
On 1/12/15 2:50 AM, Sergey Bylokhov wrote:
Hello.
Please review a fix for jdk 9.
BufferedImage::getPropertyNames() was implemented according to
specification.
Notes:
- The properties map in the constructor is defined as , which means
it can have non-String k
Hi Alexander,
The code that lets someone modify an existing image has an important and
undesirable side effect of making images mutable. Since we cache images
internally, they are treated as immutable so that if two unrelated
parties ask for an image that comes from a specific URL, we can giv
The second solution looks good. I'd make it standard practice (perhaps
even mentioned in the documentation) to return unmodifiable lists from
the getVariants() method. The Collections class provides easy methods
to create these lists, and it sends a clear message to the caller that
the list w
Hi Prasanta,
This fixes the symptom without fixing the underlying issue which is that
there is poor sharing of information between the objects in the Pisces
package. The cache adds 1 to bboxX1 and bboxY1 for its own internal
purposes - and it seems extremely questionable that it should do so
Hi Laurent,
On 2/24/15 6:51 AM, Laurent Bourgès wrote:
FastPath2D would be public API. Perhaps that should be a separate
discussion
FastPath2D is only a improvement of the Path2D class to trim arrays in
the clone() method but there is another solution: provide a new Path2D
constructor
...jim
On 2/24/15 9:33 AM, Jim Graham wrote:
Hi Laurent,
On 2/24/15 6:51 AM, Laurent Bourgès wrote:
FastPath2D would be public API. Perhaps that should be a separate
discussion
FastPath2D is only a improvement of the Path2D class to trim arrays in
the clone
Those changes were exactly what I was referring to. I don't see why we
shouldn't make trimmed arrays when copying the shape. I'm pretty sure
that the copy constructors are going to be overwhelmingly used to make a
protected copy of an existing shape/path2d which is likely meant mostly
for rea
k.java.net/~serb/prasanta/8048782/webrev.01/
Regards
Prasanta
On 2/21/2015 2:57 AM, Jim Graham wrote:
Hi Prasanta,
This fixes the symptom without fixing the underlying issue which is
that there is poor sharing of information between the objects in the
Pisces package. The cache adds 1 to bboxX1 and
r.openjdk.net> !
Regards,
Laurent
Le 25 févr. 2015 02:06, "Jim Graham" mailto:james.gra...@oracle.com>> a écrit :
Those changes were exactly what I was referring to. I don't see why
we shouldn't make trimmed arrays when copying the shape. I'm pretty
w 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 Graham" a écrit :
Those changes were exactly what I was referring to. I d
mCopy.
Please tell me if the test is correct as I do not run it with jtreg
(annotations ?)
2015-02-25 2:05 GMT+01:00 Jim Graham mailto:james.gra...@oracle.com>>:
Those changes were exactly what I was referring to. I don't see
why we shouldn't make trimmed
First, the test cases that I asked for were to verify that a path that
was cloned was still operational. I see no tests that verify that the
returned objects will still function, only tests that examine internal
data structures for a metric that may not be appropriate in the future.
On 3/6/15
On lines 228 and 1069 you should not mix p2d and this. I would go with
both p2d.pointTypes and p2d.numTypes in both cases...
...jim
On 3/6/15 2:03 PM, Laurent Bourgès wrote:
Phil,
Here is a new webrev:
http://cr.openjdk.java.net/~lbourges/webrev_Path2D_1/
See my comm
(insofar as I
don't remember there being a bug/rfe filed against it).
It should certainly be filed as an RFE and we can discuss the technical
hurdles and the workarounds in that context and gauge the level of
interest from the community...
...jim
On 3/10/15 1
Serializing images by content is generally wasteful in terms of the size
of the data stream.
For images loaded from a URL or file, presumably those can be reloaded
by the application if it has a way to retrigger loading its resources (a
common technique is to lazily load some images or have a
ge interface
- base image size arguments are removed form the
getResolutionVariant(...) method in MultiresolutionImage interface
- BaseMultiResolutionImage class that allows to create a
multi-resolution image based on resolution variant array is added
- the test for the BaseMultiResoluti
On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages
easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all
want that?
Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be
the difference)...
...jim
On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
On Mar 26, 2015, at 22:52, Jim Graham wrote:
On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages
easily to something that
On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
If my understanding of the current drawing pipeline is correct, RGBA without
premultiplication is slow as premultiplication is done on-the-fly when
drawing—at least for OS X and OpenGL, as pointed out in
https://bugs.openjdk.java.net/browse/JDK-8059
ds
array is zero-sized (0 capacity constructor): bug present in jdk8
- new tests:
Path2dEmpty to test this bug
Path2dCopyConstructor to test my changes on the copy constructor
following your instructions
Maybe we should create a new bug and split this patch in 2 separated ones ?
Laurent
Le 7 mar
Thanks Sergey,
Have you been following the rest of this thread? Any thoughts on how
much the lack of PRE pixel format in the PNG loader might be hurting us?
...jim
On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
28.03.15 0:50, Jim Graham wrote:
On 3/27/15 3:48 AM
Hi Laurent,
Test program, line 490 - MOVETO has 2 coordinates associated with it.
Test program, line 492 - perhaps we should throw an exception on default
since it indicates a problem with the iterator
Other than that, it looks good...
On 3/29/15 7:40 AM, Laurent Bourgès wrote:
- What am I
ll it somehow cause the
resulting cached uploaded texture to underperform once it is living on
the GPU? Or are there common operations on Toolkit images where we do
not use a cached texture?
...jim
On 3/30/15 12:28 PM, Sergey Bylokhov wrote:
28.03.15 4:10, Jim Graham
Hi Laurent,
On 3/30/15 2:31 PM, Laurent Bourgès wrote:
Big one: I figured out a bug in Path2d happening with 0 capacity:
rectCrossing and ptCrossing fail.
I'm guessing that is why there are the new shortcut returns on the
intersects/contains methods in Path2D? I see it
All of your comments are spot on (modulo the confusion over
Pisces/Marlin vs Path2D). And you are right that 500 seems pretty lean
to me. 800K path segments seems to be a pretty large outlier, though,
do we really see paths that large other than via a test case?
I think I'm good with the pro
The fix looks good. +1
...jim
On 4/1/15 3:55 PM, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8075942
http://cr.openjdk.java.net/~prr/8075942/
It appears that the amount to grow the array is not taking into account
that before the System.arraycopy we first store '
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.
I looked at the ArrayList code and found a bit of voodoo there in the
overflow code which troubled
Hi Andrea,
On 4/3/15 7:01 AM, Andrea Aime wrote:
PS: GeoServer will clip and simplify the geometry before
throwing it at java2d, exactly because we know
java2d is not so good at handling this kind of complexity
Do you have a fast and efficient polygon clipper in g
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 also a clipping
implementation but is known too be very slow as the shape complexity
increases !
The Area class is mostly a red herring.
the
variants.
...jim
On 4/1/15 6:46 AM, Alexander Scherbatiy wrote:
On 3/27/2015 12:48 AM, Jim Graham wrote:
Hi Alexander,
http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
I have updated the fix according to the comments except
RenderingHints.
RenderingHints are s
6, 2015 at 11:59 PM, Jim Graham mailto:james.gra...@oracle.com>> wrote:
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
<https:/
e to implement & test for a general usage or in
particular for pisces / marlin renderers. For 2 years, it remains in my
TODO list ... as many applications already have their own (custom) solution.
Please read my comments below:
Le 7 avr. 2015 00:38, "Jim Graham" mailto:james.gra...@or
ize = newsizemin + (newsize - newsizemin) / 2;
}
...jim
On 4/8/15 9:34 AM, Laurent Bourgès wrote:
Jim,
let's go back to concrete code:
2015-04-04 0:25 GMT+02:00 Jim Graham mailto:james.gra...@oracle.com>>:
The patch as it is will make things much better, but it
Phil?
...jim
On 4/17/15 3:09 AM, Laurent Bourgès wrote:
Phil & Jim,
Do you have any feedback (CCC) on this Path2D patch ?
http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.1/
<http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D_needRoom.1/>
Laurent
Le 10 avr. 2015 20:
For reference: https://bugs.openjdk.java.net/browse/JDK-8078192
...jim
On 4/20/15 1:09 PM, Jim Graham wrote:
I've started the CCC process by creating a bug.
One quick question - do we want to port these changes back to 8u60? If
so, then we would not be able to
ourges/path2D/Path2D_needRoom.1/
Changes:
- needRoom() applies your pseudo-code; see expandPointTypes() and
expandCoords()
- added a new public trimToSize() method to Path2D implemented by both
Path2D.Float and Path2D.Double classes
Cheers,
Laurent
2015-04-08 22:53 GMT+02:00 Jim Graham mailto:james.gra..
On 4/20/15 1:37 PM, Jim Graham wrote:
In the needRoom() methods, there is one more potential overflow path. If
the array grows to just under MAX_INT, then "numCoords + newCoords" may
overflow to a negative number and the array would not be grown because
the test in needRoom() wou
The math looks fine to me. We'll need to coordinate this with changes
for Windows HiDPI as well...
...jim
On 4/20/15 4:48 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8069361/webrev.01/
- CGraphicsConfig
D'oh, make that ">" instead of "<"... ;)
...jim
On 4/20/15 1:47 PM, Jim Graham wrote:
On 4/20/15 1:37 PM, Jim Graham wrote:
In the needRoom() methods, there is one more potential overflow path. If
the array grows to just under MAX_INT, t
value of the new overflow protection is not enough to further
split this particular change down...
...jim
On 4/20/15 1:09 PM, Jim Graham wrote:
I've started the CCC process by creating a bug.
One quick question - do we want to port these changes back to 8u60? If
so,
Actually, one comment on the doc comment formatting.
I'd use "{@code Path2D}" instead of "" formatting. It gives
the javadoc front end more control over the presentation...
...jim
On 4/20/15 1:37 PM, Jim Graham wrote:
Hi Laurent,
The new doc comm
new
trimToSize () methods.
Le 21 avr. 2015 00:11, "Jim Graham" mailto:james.gra...@oracle.com>> a écrit :
To answer my own question - since we already have a changeset with just the new
trim-on-copy stuff that is backwards compatible and since this change only adds
the new trim meth
401 - 500 of 822 matches
Mail list logo
