[Bug]: The app freezes when clicking on a GIF image

[Olkris2666]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

TagStudio Version

9.5.0 PR4

Operating System & Version

Windows 11

Description

Whenever I click on a GIF file, TagStudio will freeze until the file is loaded fully, rendering the UI unusable and interrupting the flow of tagging files.

In my experience this takes 11 seconds for a 20Mb GIF file.

It also makes it impossible to click away to another file to interrupt the loading. You can click on other files, but the UI will remain frozen and only buffer the change to the other file once that GIF has finished loading.

Expected Behavior

TagStudio should remain operational and keep it's ability to tag a file even if the image or video it contains hasn't been loaded by the UI yet.

Additionally, GIF files should be treated as video within the TagStudio UI if possible, benefiting from the option to pause the file and disable autoplay through the same setting as would apply for MP4 files.

Steps to Reproduce

1. Click on a GIF file. The app will freeze until loaded.

Logs

No response

[CyanVoxel]

Pasting my comment from the discord for more context as to what's going on here:

And the reason it freezes for a moment for loading gifs since 9.4 is because I had to make it load the whole gif file first into memory as bytes instead of streaming the file from disk, since the player would lock lock access to the file which made it so you couldn't delete whatever gif was being played in the preview panel or whichever one was last played

Videos had a similar issue but I was able to do a trick where I swap out the current video playing for a blank placeholder one right before deleting the file and that frees up the file accesss. The same trick didn't work for the gif player

Also other animated image formats that Qt doesn't support (wepb or apng I think) are loaded into memory first as bytes and then converted to gifs in-memory to make them playable

This issue was initially introduced in #409 for the Alpha-v9.4 branch and it's respective port to main, #659

[CyanVoxel]

The slowdown is specifically caused by the anim_image.save() call inside _update_animation() of preview_thumb.py.

For some additional clarity as to what happened in #409: We used to use QMovie(str(filepath)) to load GIFs as this would simply stream the file from disk rather than load into memory and then save it back to a GIF format from bytes. But streaming from disk had the side-effect of locking the file access, even when the QMovie was stopped and replaced by another file, so something had to be changed when file deleting was added.

The following comment in #409 shows the method that worked for freeing up disk access for video files but shows how the same trick didn't work correctly for GIFs:

    def stop_file_use(self):
        """Stops the use of the currently previewed file. Used to release file permissions."""
        logging.info("[PreviewPanel] Stopping file use in video playback...")
        # This swaps the video out for a placeholder so the previous video's file
        # is no longer in use by this object.
        self.preview_vid.play(ResourceManager.get_path("placeholder_mp4"), QSize(8, 8))
        self.preview_vid.hide()

        # NOTE: I'm keeping this here until #357 is merged in the case it still needs to be used.
        # logging.info("[PreviewPanel] Stopping file use for animated image playback...")
        # logging.info(self.preview_gif.movie())
        # if self.preview_gif.movie():
        #     self.preview_gif.movie().stop()
        # with open(ResourceManager.get_path("placeholder_gif"), mode="rb") as f:
        #     ba = f.read()
        #     self.gif_buffer.setData(ba)
        #     movie = QMovie(self.gif_buffer, QByteArray())
        #     self.preview_gif.setMovie(movie)
        #     movie.start()

        # self.preview_gif.hide()
        # logging.info(self.preview_gif.movie())

Although looking at this, maybe it failed because the movie was replaced by an in-memory QByteArrary rather than another file on disk?