[OpenJDK 2D-Dev] [8] request for review: 8026702: Fix for 8025429 breaks jdk build on windows
Hello, could you please review a fix for CR 8026702? Bug: http://bugs.sun.com/view_bug.do?bug_id=8026702 Webrev: http://cr.openjdk.java.net/~bae/8026702/webrev.00/ Suggested fix is to declare local variables in the beginning of the function. Please take a look. Thanks, Andrew.
Re: [OpenJDK 2D-Dev] [8] request for review: 8026702: Fix for 8025429 breaks jdk build on windows
Looks good. On 16.10.2013 17:00, Andrew Brygin wrote: Hello, could you please review a fix for CR 8026702? Bug: http://bugs.sun.com/view_bug.do?bug_id=8026702 Webrev: http://cr.openjdk.java.net/~bae/8026702/webrev.00/ Suggested fix is to declare local variables in the beginning of the function. Please take a look. Thanks, Andrew.
[OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8026702: Fix for 8025429 breaks jdk build on windows
Changeset: 070e8ec9d82c Author:bae Date: 2013-10-16 17:13 +0400 URL: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/070e8ec9d82c 8026702: Fix for 8025429 breaks jdk build on windows Reviewed-by: serb ! src/share/native/sun/java2d/cmm/lcms/LCMS.c
[OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455
Hi, As Jim pointed out, my earlier fix for bug JDK-7159455 wasn't entirely correct as it allowed some shear-transformations to pass a check for a fast-path although they should have been rejected. He proposed a way of using the capabilities already provided by AffineTransform, which is correct, shorter and most likely more efficient (thanks!). Please find the follow-up fix for JDK-7159455 at: http://cr.openjdk.java.net/~ceisserer/fix12/webrev.00/ Thanks, Clemens
Re: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8026702: Fix for 8025429 breaks jdk build on windows
Oops! Thanks, Johnny Chen On Oct 16, 2013, at 6:15 AM, andrew.bry...@oracle.com wrote: Changeset: 070e8ec9d82c Author:bae Date: 2013-10-16 17:13 +0400 URL: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/070e8ec9d82c 8026702: Fix for 8025429 breaks jdk build on windows Reviewed-by: serb ! src/share/native/sun/java2d/cmm/lcms/LCMS.c
[OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test
Changeset: 73d212a3b2eb Author:jchen Date: 2013-10-16 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/73d212a3b2eb 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
Re: [OpenJDK 2D-Dev] RFR: Backport to jdk7 -- [macosx] Java crashed on mac10.9
Looks fine. With 10.9 releasing soon we'll need this in JDK 7. You will need to send a request to 7u-dev asking for an OK to pus this. -phil. On 10/16/2013 2:11 PM, Johnny Chen wrote: http://cr.openjdk.java.net/~jchen/8024461.jdk7/ Thanks, Johnny Chen
Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455
Hi Clemens, Now that we've narrowed it down to a quadrant rotation at best, can't we get by with only transforming x,y and x+w,y+h? Or is the adjust method used from other locations that might have a non-quadrant transform? (Or do any callers depend on srcCoords and dstCoords being fully populated?). If it's a mixture of quadrant and general transforms, then I think it may make sense to have the adjust method do the test, determine how much it needs to transform, and then return the result, but that is probably a minor optimization compared to other work going on (not sure if benchmarks would notice the difference). I also noticed that the bounds are rounded. If the intent is to catch every single pixel, then shouldn't those be floor/ceil operations? If the intent is to rasterize the transformed rectangle then filled rectangles (and shapes) use a round down calculation, but Math.round() is a round up calculation. How is the resulting compositeBounds used? Also, I noticed that you added a new wild-card import into one of the files. I believe we deprecated that practice in the FX source base, but I don't know what the standard practice is in OpenJDK and didn't see any statements about it in the OpenJDK style guildelines. ...jim On 10/16/13 10:55 AM, Clemens Eisserer wrote: Hi, As Jim pointed out, my earlier fix for bug JDK-7159455 wasn't entirely correct as it allowed some shear-transformations to pass a check for a fast-path although they should have been rejected. He proposed a way of using the capabilities already provided by AffineTransform, which is correct, shorter and most likely more efficient (thanks!). Please find the follow-up fix for JDK-7159455 at: http://cr.openjdk.java.net/~ceisserer/fix12/webrev.00/ Thanks, Clemens
