updated initialization variables.

Please check a comment.

looks fine to me, if there is any proper result of this, it would be nice.

Please check a comment.

Please check a comment.

Please check a comment.

This is not a common feature.

how this patch helps to this scenario:

good to me.

Please keep code convention. We prefer simpler way.

This looks good to me if agrresive optimization helps for better performance.

this looks wrong to me.
if user need the actual bound of the shape trees from the container, how they make it?

what happens if r is not initialized at this condition? if (pd->viewbox.w != 0 && pd->viewbox.h !=0)

In D11926#228382, @raster wrote:

do we really need 1.1.0? i have a debian installation my rockpro64 and it compiles and runs fine with 0.6.1. it can load webp images. no symbol errors, crashes or compile errors. i am thinking of dropping this down to 0.6.1 as at least empirically that is good enough (and it'd allow the CI build envs to re-enable webp again). upstream libwebp added WebPAnimDecoder in d39dc8f3cc07f0fffb73def2125ddcdf8073eafcwhich was back in september 2015. 0.6.1 came out nov 2017. so i think this is safe. possibly earlier versions might be fine too. 0.5.0 probably is the baseline for this actually (came out end of 2015 or so), but i can confirm 0.6.1 is seemingly fine. in fact i think i will drop it to 0.5.0 and then see if people complain because the anim api did come out in 0.5.0

Please check comments.

Unnecessary check. eo handles invalid objects (including nullptr) internally.

Last comment!

Please check comments.

I think we can only support Legacy API, not interface.

great!

Please check my comments.

holding review, I will check it later.

@kimcinoo Could you please verify this?

In D11926#227490, @stefan_schmidt wrote:

Looks good to me. What is the reason we need version 1.1.0? A specific API we use or a bugfix we need? Would be good to record the reason for the version in the commit message.