Closed ObaraEmmanuel closed 1 year ago
Are you certain? It's my understanding that from the git spec a frame can omit pixels which is why we must draw over the previous...
Perhaps there is a difference between a transparent pixel and a mixing pixel?
Are you certain? It's my understanding that from the git spec a frame can omit pixels which is why we must draw over the previous...
Perhaps there is a difference between a transparent pixel and a mixing pixel?
Maybe the spec says to draw over I am not sure. But the GIFs seemed to render properly everywhere else except in fyne. Maybe there is some metadata included with the GIF that specifies the different behaviour that we are not considering?
Okay, we need to factor in disposal for each frame for the correct handling. The GIF struct has a disposal array with disposal info for each frame which can be used. Let me apply the correct Porter-Duff operator based on this disposal attribute and see the results
That sounds like what I figured - thanks for digging in further
I was using the animated GIF in my projects and noticed it was not correctly rendering GIFs with transparent sections. Further investigation showed that is was because of the use an improper Porter-Duff operator. The operator in use before was
Over
which means on subsequent renders, transparent section would contain pixels from the previous frame. This PR is a simple fix that uses theSrc
operator instead. This ensures the new frame overwrites the previous one completely allowing transparent regions to be rendered correctly on subsequent frames. This change will not result in any regressions because for non-transparent GIFs the two operators (Over
&Src
) behave essentially the same way.