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
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 comment and method looks good.
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 method and some overflow protection, we
can just go with the previous fix if we decide to backport things. The
added valu
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, then "numCoords + newCoords" may
o
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
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() would fail to trigge
Hi Laurent,
The new doc comment and method looks good.
Arrays.copyOf is often faster than allocation+arraycopy (typically
because it doesn't need to clear the entire array first and then fill it
with data in 2 separate passes - Hotspot optimizes that method into a
single operation). The new
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 port the
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 port the new Path2D method since there
are no API changes allowed in 8u60. If not, then there is no issue.
Phil?
.
The fix looks fine to me. It will be good if an SQE team will port this
test to the jdk ws.
On 27.03.15 17:50, Andrew Brygin wrote:
There is a minor update in the fix: it does not worth to blend
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes
no difference.
Looks fine.
On 20.04.15 22:07, Andrew Brygin wrote:
Hi Phil,
it looks fine to me.
Thanks,
Andrew
20/04/15 21:49, Phil Race пишет:
Andrew & Sergey,
Please review this identical 8u60 backport (diff below) of the JDK 9
fix : http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b7e402c9b183
hg diff i
Hi Phil,
it looks fine to me.
Thanks,
Andrew
20/04/15 21:49, Phil Race пишет:
Andrew & Sergey,
Please review this identical 8u60 backport (diff below) of the JDK 9
fix : http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b7e402c9b183
hg diff imageioJPEG.c
diff --git a/src/share/native/sun/awt/ima
Andrew & Sergey,
Please review this identical 8u60 backport (diff below) of the JDK 9 fix
: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b7e402c9b183
hg diff imageioJPEG.c
diff --git a/src/share/native/sun/awt/image/jpeg/imageioJPEG.c
b/src/share/native/sun/awt/image/jpeg/imageioJPEG.c
--- a/s
Hello Phil,
the change looks fine to me.
Thanks,
Andrew
On 4/18/2015 12:19 AM, Phil Race wrote:
http://cr.openjdk.java.net/~prr/7145508/
https://bugs.openjdk.java.net/browse/JDK-7145508
If you physically disconnect the monitor and run headful, then on X,
the XR&R
extension will return NUL
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8069361/webrev.01/
- CGraphicsConfig.getDefaultTransform() is updated to use
AffineTransform.getScaleInstance()
- SG2D.getDefaultTransform() is updated to not check
GraphicsConfiguration.getDefaultTransform() on null
Looks good to me.
/Erik
On 2015-04-17 14:52, Magnus Ihse Bursie wrote:
With JDK-8074096, the number of warnings in the product was reduced to
a minimum. This enables the next step, which is turning on the
respective compiler flags that turns warnings into errors. In the long
run, this is the
16 matches
Mail list logo
