-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8312191: ColorConvertOp.filter for the default destination is too slow #14910
Conversation
👋 Welcome back serb! A progress list of the required criteria for merging this PR into |
Webrevs
|
@mrserb This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
keep open |
@mrserb This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
keep open |
@mrserb This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit e5f05b5.
Your commit was automatically rebased without conflicts. |
I have found that MTPerLineTransformValidation - one of our slowest stress test spends most of the time not in the code related to the colors conversion(as it was intended) but in the initialization of the native cmm-transforms.
The code above triggers the next sequence:
So the critical thing above is to minimize the creation of the new color spaces, since for each new space all optimizations above should be repeated. Unfortunately, when we create the ColorConvertOp using standard icc_profile/icc_colorspace we store the profile only and lost the reference to the initial color space. And when later we decide to create a color model we create the new icc_color space->all optimizations resets.
We do not save the reference to the color space because that way we distinguish the icc_colorspace saved using profiles, and non-icc_color spaces used as is. I think all that code should be reworked to take into account the current issue. But for now, we can fix it at least for standard types.
Important notes:
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14910/head:pull/14910
$ git checkout pull/14910
Update a local copy of the PR:
$ git checkout pull/14910
$ git pull https://git.openjdk.org/jdk.git pull/14910/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14910
View PR using the GUI difftool:
$ git pr show -t 14910
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14910.diff
Webrev
Link to Webrev Comment