Closed Bug 505959 Opened 15 years ago Closed 11 years ago

ExtractCurrentFrame should not create an imgContainer

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bholley, Unassigned)

References

Details

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?
I'll have my hands full with XPConnect and js-ctypes for the foreseeable future - resetting assignee to default.
Assignee: bobbyholley+bmo → nobody
This was fixed in bug 826093.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 826093
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.