505959 - ExtractCurrentFrame should not create an imgContainer

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Bobby Holley (:bholley)]

Now that bug 753 has landed, we have an imgIContainer method ExtractCurrentFrame which creates a new imgIContainer with 1 internal frame, sourced from the currently active frame within the original container and cropped to the desired size. This is currently only used by borderImage, which more or less just extracts part of the frame, calculates some rectangles and coordinates, and draws it.

In my decode-on-draw work (bug 435296), I do quite a bit of re-architecting in imgContainer. The design philosophy is that imgContainer should map an encoded image (like a jpeg or png) to decoded frames, storing the source data from decode-on-draw or discard-redecode if necessary. This works great most of the time, but the one case where it doesn't is ExtractCurrentFrame, because there's no source data and no mimetype. The patch currently kludges things to pass in an empty mimetype and do some special handling, but this ideally should go away.

Thus, I propose that we make a different class called something like imgFrameContainer (anyone have a better name?), which of course also implements imgIContainer, and has slimmed down internals for more or less just wrapping a single frame. This separates the two uses, and doesn't publicly expose any 'frame-ish' datatype, which joe would be against.

I'll probably start work on this soon after bug 435296 lands.

Comments?

Comment 1

[Bobby Holley (:bholley)]

I'll have my hands full with XPConnect and js-ctypes for the foreseeable future - resetting assignee to default.

Comment 2

[Seth Fowler [:seth] [:s2h]]

This was fixed in bug 826093.