Closed Bug 1116737 Opened 8 years ago Closed 8 years ago
Blender into Frame Animator
After bug 1116716, FrameBlender just isn't doing very much by itself anymore - it stores a couple of compositing frames, but other than that it's mostly a set of utility methods for FrameAnimator to call. In future bugs we're going to want to do refactorings that cut across both the code in FrameAnimator and the code that's currently in FrameBlender. I think it makes sense at this point to merge FrameBlender into FrameAnimator, which will provide a good foundation for those future refactorings.
Here's the patch. It's purely refactoring. Basically, the member variables and code from FrameBlender gets moved into FrameAnimator, with the exception of the enumerations, which turn out to make more sense living in imgFrame's header file. Then all the code that references those things gets updated.
Attachment #8542923 - Flags: review?(tnikkel)
Try job here: https://tbpl.mozilla.org/?tree=Try&rev=d18c17a28fe1
Attachment #8542923 - Flags: review?(tnikkel) → review+
Thanks for the review! The failures in the try job above are all from previous patches in the patch stack, and they've now been fixed. The one exception was a failure to build on Windows because the TRANSPARENT identifier is used. =\ To work around that I renamed TRANSPARENT to SOME_TRANSPARENCY, and building on Windows is now successful, as this try job shows: https://tbpl.mozilla.org/?tree=Try&rev=aa5ade79fd8b Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/689797cc26c4
Here's the final version of the patch that got pushed.
Attachment #8542923 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.