808189 - Implement image clipping via a wrapper imgIContainer

Status: RESOLVED DUPLICATE of bug 826093

(Core :: Graphics: ImageLib, defect)

Description

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

Currently there are some issues in the way that ExtractFrame(), and thus spatial media fragment support, behaves. The biggest are:

- When you use ExtractFrame() on a RasterImage, the resulting image contains only one frame (logically enough) and doesn't animate. When you use it on a VectorImage, the resulting image animates. This is inconsistent, and wrong for both the ExtractFrame() case (where you should never have animation) and the media fragments case (where you always should).

- VectorImage's GetWidth() and GetHeight() don't behave correctly if the VectorImage was created by ExtractFrame().

- Clipping RasterImages involves copying the image data. Sprite sheets are expected to be a common use case for media fragments and I suspect that copying each sprite's subimage out will probably not be as performant an approach as just drawing the original sprite sheet clipped. Also, copying a subimage of an animated image can be rather awkward if we still want to be able to start displaying the image immediately as soon as the first frame is decode.

- Because VectorImages lack an intrinsic width and height in many cases, clipping has to be applied lazily at the time of the Draw() call. This ends up duplicating some of the clipping logic in multiple places in the code.

A better approach would be to create a new class that implements imgIContainer - let's call it ClippedImage - which creates a clipped version of an underlying imgIContainer that it wraps. At construction time it should be specified whether the clipped image should animate or not, so that both media fragments and ExtractFrame() can be implemented in terms of this class.

ClippedImage would override GetWidth(), GetHeight(), Draw(), and perhaps a few other calls; other things would be passthrough. The actual clipping would typically applied by modifying the arguments to the Draw() call, although it'd be possible to cache the clipped version as well. ClippedImage objects would thus typically be quite lightweight, containing only the clipping metadata, and all necessary logic would be centralized there.

ExtractFrame() and media fragments will have a much simplified and more consistent implementation as a resulted of ClippedImage, and VectorImage objects in particular will be more lightweight since they no longer will need the concept of a "restricted region".

There are several places in the code that assume that an imgIContainer is either a RasterImage or a VectorImage; those sites will have to be updated to eliminate that assumption.

Comment 1

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

Adding dependence on bug 811129 to ensure that that bug's changes don't interfere with this one.

Comment 2

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

This is happening in bug 826093.