mouse ear gets stuck

[duyenlv]

Hi team. I have an issue could you help?

I used APNGKit v2.0.2, it works for me with almost apng images, but I encountered an issue with

https://user-images.githubusercontent.com/2205362/144172712-94f36430-1c48-42b1-9953-37d784123544.mov

I tried view this image on the Safari browser (Mac OS) with url: file:///Users/../Downloads/mouse.png - no stuck ear.

[duyenlv]

If I use v1.2.3, this problem is not occurred.

[onevcat]

In fact I am seeing this "stuck" in the Finder preview as below:

It is either a poorly clear flag in the APNG file, or a bug in clearing previous content. I will investigate it when I have time.

[onevcat]

@duyenlv I checked the provided image and now I can say it is an image issue. I will explain it a bit better in following.

I added a frame debugging view controller in the demo app and checked the frames of this image:

The yellow area indicates the full image size, and the orange overlay layer is the drawing area defined in this frame:

• In frame #5, the mouse is drawn from {60, 35}, so it means the ear starting from Y: 35.
• In frame #6, it has a dispose Previous. This flag means, when rendering the next frame (#7), the content in region of current frame ({60, 38}, 360x329) should be reverted to the content in the previous frame #5.
• That means, in the rendered image of #6, the pixels below Y: 38 will be reverted to those pixels from #5, then the reverted canvas will be used as the starting point for rendering of frame #7.
• Since the ear of #5 starts from 35, and the ear of #6 starts from 38, reverting contents below 38 won't change the starting point of ear.
• On the other hand, the rendering area of #7 starts from Y: 45. That means, any pixel above 45 won't get updated.

So, in the following frames, until the pixels above Y: 35 can be drawn again, the ear will keep starting from Y: 35.

That means, any implementation can display that image without a "persistence" might be doing wrongly. Maybe it is a good idea to check your APNG creating or exporting tool to make sure it is correctly following APNG spec.

Sure I can be wrong, please feel free to let me know if I made a mistake above.

[duyenlv]

@onevcat Thanks for your explanation, I encounter this issue with Mac Finder too, I am working for client's project, they ask me a question that the problem isn't occurred while running both Web Browser (you can drag the file to the browser address bar) and Android app (use https://github.com/penfeizhou/APNG4Android), but it's occurred in iOS app (use this library). So that I have to revert to APNGKit v1.2.3 to make sure the ear doesn't get stuck. Did you compare your two versions?

[onevcat]

First, the browser implementation for APNG is very buggy, especially for Safari. You may check this page (https://philip.html5.org/tests/apng/tests.html) with Safari to see quite a few red blocks, which indicates the failing case. Especially for the previous dispose op, it does not follow the APNG spec at all.

APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.

For https://github.com/penfeizhou/APNG4Android, I checked the code and it copies the previous content to the bitmap, but never draw it back to the canvas. (Again, I am not an expert of Android so I can be wrong.)

Also, the old implementation of APNGKit v1.x was definitely wrong.

For now, to me, it is quite strange that the image is using a previous dispose op in these frames. That flag is being used to keep minimal drawing requirement if most of the content is the same (like the screenshot below). In your case, it is not that case and the easiest solution seems to be recreating your image with all dispose set to background.

[onevcat]

@duyenlv I guess it was my mis-understanding of the spec. A PR was made to fix this issue and I will tag it soon once merged.

Thanks for reporting it and the discussion!

[onevcat]

Version 2.1.2 was released and this issue should be fixed.