RFR: 8339974: Graphics2D.drawString doesn't always work with Font derived from AffineTransform [v4]
Phil Race
prr at openjdk.org
Tue Oct 8 17:08:10 UTC 2024
On Mon, 7 Oct 2024 22:06:06 GMT, Daniel Gredler <duke at openjdk.org> wrote:
>>> Interesting idea. I personally don't know enough to weigh in on whether the benefits of saving to disk outweigh the drawbacks. It might be possible to emit the Base64-ed PNG to sysout or syserr (these images should compress very well as PNG), but keep in mind that these two tests are headless and drawing to an in-memory `BufferedImage`, so the usage might be a little different than the screenshot-focused solution outlined in JDK-8328716.
>>
>> There is no issue saving to disk.
>> If there were, we'd have big problems because that's where the class files go !
>> Doing what I suggested is the way to go.
>
>> It is perfectly fine. We do this in many tests.
>
> OK, thanks for the clarification.
>
>> OTOH I don't think it necessary to print the absolute path.
>
>> Doing what I suggested is the way to go.
>
> Just to be clear then -- the test should continue to save the images to disk on failure, but should not include the file path in the error message, correct? I can update the PR if that's the case.
Right.
And actually the best thing when saving the file would be to to get the dir path to save to from using
something like this
String dir = System.getProperty("test.classes", ".");
String filename = dir + java.io.File.separator + basename + ".png";
This ensures it is saved the same place as jtreg puts the class files and if that is not defined (ie you are running it outside jtreg), then in the current dir.
But no need to "print" that path.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20993#discussion_r1792229116
More information about the client-libs-dev
mailing list