RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard

[Alexey Ivanov]

On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Problem:**
> 
> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time.
> Due to this infinite wait the application freezes.
> 
> **Proposed Fix:**
> 
> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn’t keep waiting, as it leads to infinite wait. 
> After this change I see the GIF image being correctly copied and animated.
> 
> 
> **Testing:**
> 
> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5.

> > Yes i mean generating GIF by code and not using .gif file as input.
>
> Will the generated GIF file be animated ?, because this only happens with animated GIFs. And why is it better than having the GIF file itself ?

It should if you create several frames.

There's always an option to create another GIF image, smaller, and use its byte or base64 representation as the source.

> We try to avoid adding new image file to JDK repo whenever we have some ImageIO test because it increases the size, so its better to use stream or create and delete temp file in regression tests.

Okay, now it's clear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1507282776