Skip to content

Conversation

dreampiggy
Copy link
Contributor

@dreampiggy dreampiggy commented May 14, 2019

PR description

There are a critical bug in the SDAnimatedImageCoder protocol implementation for animatedImageFrameAtIndex:.

The implementation which use the optimization to avoid random access for webp frame, have a bug to detect which frame can be safelly blend start with.

The relative code can be checked there in YYImage-YYImageCoder.m

Bugfix

For example, this WebP image:
http://i1.chuimg.com/d76f3bed2a67462994cf0bac727f68b7_1080w_606h.webp

It has the following frame info:

Canvas size: 1080 x 606 Features present: animation transparency Background color : 0xFFFFFFFF Loop Count : 0 Number of frames: 24 No.: width height alpha x_offset y_offset duration dispose blend image_size compression 1: 1080 606 no 0 0 125 none no 49642 lossy 2: 1080 606 yes 0 0 125 none yes 49030 lossy 3: 1080 606 yes 0 0 125 none yes 50154 lossy 4: 1080 606 yes 0 0 125 none yes 50704 lossy 5: 1080 606 yes 0 0 125 none yes 48484 lossy 6: 1080 606 yes 0 0 125 none yes 49138 lossy 

The bug screenshot:

The frame 2, which use blend == yes, should keep the frame 1's draw context, and blend on it. But however, current implementation ignore this.

See the debug result for the frame 2 representation, which does not have frame 1's blend draw at all. Instead it use a clear context for drawing (CGContextClearRect)

Fix

The correct result:

…lend from the first frame, impact the `SDAnimatedImage`
Copy link
Member

@kinarobin kinarobin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dreampiggy. Now It works well in my project.

@kinarobin kinarobin merged commit 0713611 into master May 15, 2019
@kinarobin kinarobin deleted the bugfix_webp_blend_canvas branch May 15, 2019 05:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

2 participants