RFR: 8355078: java.awt.Color.createContext() uses unnecessary synchronization
Phil Race
prr at openjdk.org
Fri May 9 21:43:51 UTC 2025
On Sun, 20 Apr 2025 08:15:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
> At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
>
>
> Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering.
>
> Two tests are added:
> - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior.
> - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster()
Marked as reviewed by prr (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24771#pullrequestreview-2829740767
More information about the client-libs-dev
mailing list