Hi Jeremy, Laurent,
Thanks for having a look. What sorts of changes are you thinking of when
you propose a separate project?
For myself, I don't really have a bigger-picture vision of systematic
changes that I'd like to make. Similar to JDK-8337681, JDK-8344668 and
JDK-8356814, this suggestion is
OK, thanks -- I'll add a `colorModel.getColorSpace().isCS_sRGB()` check
here as well.
Take care,
Daniel
On Thu, Sep 4, 2025 at 11:55 PM Philip Race wrote:
> It doesn't seem like a change that needs a project.
> I would make sure that call to colorModel.getRGB(..) isn't needed and I
> think t
It doesn't seem like a change that needs a project.
I would make sure that call to colorModel.getRGB(..) isn't needed and I
think that you aren't doing that.
Basically it needs to be sRGB already (as that is the target color space).
-phil.
On 9/4/25 1:37 PM, Daniel Gredler wrote:
Hi Jeremy, L
Hi guys,
I do love optimizing java2d, so Ido support & sponsor your buffered image
(ARGB PRE or not) changes.
Let's start a github project to start this concrete patch... as I did for
the marlin renderer or we could use the marlin repository to host your
changes to java.awt or java2d packages.
S
if it gained traction that might
make applying some of its enhancements to BufferedImage.java more
persuasive to this group.
Regards,
- Jeremy
-- Original Message --
From "Daniel Gredler"
To client-libs-dev@openjdk.org
Date 8/22/2025 8:03:38 AM
Subject Possible Buffere
Hi all,
`BufferedImage.getRGB(int, int, int, int, int[], int, int)` is often used
for processing of individual image pixels. A common pattern is to loop
through each row of pixels, calling this method once per row to populate
the row pixel `int[]` and then process it.
There are many types of `Buf
