On Mon, 7 Oct 2024 21:53:01 GMT, Phil Race <p...@openjdk.org> wrote:
>> test/jdk/java/awt/font/FontScaling/RotatedScaledFontTest.java line 141:
>>
>>> 139: }
>>> 140:
>>> 141: private static String saveImage(String name, BufferedImage image) {
>>
>> is this a good idea to write files?
>> e.g. the CI system may not make the files accessible, the local FS might
>> overflow, etc.
>>
>> there is an idea to output base-64 encoded image to the stdout, see
>> https://bugs.openjdk.org/browse/JDK-8328716
>> this way
>> - the images will be available as long as the log file is available
>> - zero dependency on local file system or its limitations
>
>> is this a good idea to write files? e.g. the CI system may not make the
>> files accessible, the local FS might overflow, etc.
>>
>> there is an idea to output base-64 encoded image to the stdout, see
>> https://bugs.openjdk.org/browse/JDK-8328716 this way
>>
>> * the images will be available as long as the log file is available
>> * zero dependency on local file system or its limitations
>
> It is perfectly fine. We do this in many tests. jtreg ensures that CWD is the
> working directory of the test.
> it will thus be preserved along with the rest of the files jtreg preserves.
> And saving as .png lets you look at it without more hassle.
> OTOH I don't think it necessary to print the absolute path.
> Often that's on a test system you don't get to see. Instead you just get to
> downlaod the results and the absolute path is not a good idea then.
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20993#discussion_r1790924821
