Hello, Anthony. Thank you for the review.
Actually we have quite a lot of binary images in tests, but in this particular case the image could be generated on the fly. Please review the updated version of the fix: http://cr.openjdk.java.net/~pchelko/9/8024185/webrev.01/ Only test test is changed. We now generate an image for the splashscreen on the fly. With best regards. Petr. On 16.12.2013, at 23:04, Anthony Petrov <[email protected]> wrote: > Hi Petr, Phil, > > The fix looks fine to me. However, I'm not sure we want to add binary files > to the repo, no matter how good they are from "legal" perspective. > > > Phil: what do you think about .png files in tests? > > > -- > best regards, > Anthony > > On 12/16/2013 12:36 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8024185 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/ >> The fix also resolves the issue: >> https://bugs.openjdk.java.net/browse/JDK-8009203 >> >> The problem: >> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was >> invoked from within the dispatch_async. >> This is a blocking method, so it blocked the main dispatch queue which is >> used in Cocoa internally. So we've got different bugs. >> The fix replaces the Grand Central Dispatch API with the JNFRunLoop >> performOnMainThreadWaiting which is used in other places in splashscreen. >> >> The test verifies that the native FS support works after showing the >> splashscreen. Mac OS X specific APIs are accessed with reflection, so the >> test is compilable on other platforms. >> The test.png is an image added to the test folder, it's not in the webrev as >> it does not support binary file diffs. I took the image from an existing 2d >> open test, so it should be fine from the legal point of view. >> >> With best regards. Petr. >>
