On Sun, 3 Jan 2021 03:14:01 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> This change intended to enhance the lazy initialization of the standard >> color profiles concurrently by different threads. >> >> We defer standard profiles loading because most of UI application uses a >> small amount of data from the profile like numComponents and colorSpaceType, >> and this data is known in advance. But any other profile-related activity >> (like a color conversion, profile data accesses, etc.) triggers profile >> activation when we load all profile data to the memory. >> >> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: >> https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa >> >> Notes about the link above: >> - The code in the ProfileDeferralMgr, which contain the Vector of profiles >> for activation does not use any synchronization >> - The `activateDeferredProfile` and `activate` methods are implemented to >> throw `ProfileDataException`, but this exception is ignored during >> activation process: >> >> https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96 >> >> The fix: >> - Drops the usage of ProfileDeferralMgr (which contained the Vector of >> profiles for activation) and ProfileActivator machinery. Instead, we will >> have just one `ICC_Profile.activate()` method which will activate and >> initialize the `ICC_Profile.cmmProfile` if it is null >> - The `activate` method implementation mimics the old behavior when the >> CMMException and IOException were wrapped by the ProfileDataException, and >> the ProfileDataException itself was ignored during activation - > so an >> exception will not be thrown in the method itself, but only when the null >> profile will be used. >> >> See some comments inline. > > Any volunteers for a review? Any volunteers for a review? ------------- PR: https://git.openjdk.java.net/jdk/pull/1613
