Do not artificially create a frame delay for GIF files
that do not loop and have an inter-frame delay of 0. Move timeout
calculation to FrameBlender and only access raw timeout of
imgFrame from within FrameBlender.
--HG--
extra : rebase_source : 1a568f16a2980d3d14621869c6b536d054088805
This patch was generated by running include-what-you-use on image/src,
and then removing the #include statements suggested by that tool, either
replacing them with forward declarations of the used names in headers,
or dropping the ones that were completely unnecessary, and then adding
new #include statements in other places that were implicitly relying on
some of the removed #include statements.
This makes it possible for us to share FrameSequences by refcounting them. We
don't do anything smart when inserting/removing/swapping frames, but we do
carefully handle the "discard" case (by just reallocating a new
FrameSequence).
Note that, currently, nothing actually *shares* FrameSequences.
--HG--
extra : rebase_source : 9facdf8930297888f2ee77e0816543c6ad703f80
The eventual goal here is to have FrameBlenders be able to share
FrameSequences.
--HG--
extra : rebase_source : 97b8be9f53ed5cb14f0d46655d8fd7cdfa6bab67
This patch makes us store imgFrames in FrameBlender with a new sort-of-tuple,
FrameDataPair, that is smart enough to be able to lock and unlock imgFrames,
and can be transparently cast to an imgFrame, but doesn't do too much else.
The alternative, storing a separate array of uint8_t pointers, seemed too
complicated.
FrameBlender steals RasterImage::mFrames, RasterImage::DoComposite, and the
RasterImage blending helper functions CopyFrameImage, DrawFrameTo, and
ClearFrame. Now RasterImage doesn't hold on to its frames directly, and defers
all blending to FrameBlender::DoComposite.
--HG--
extra : rebase_source : f03736045f967f0947441703e54135b98d9dcf54
