Open Bug 1058941 Opened 6 years ago Updated 4 years ago
Frame' to 'Image Surface'
The name "imgFrame" isn't really a great fit for how the class is actually used in our code today. What "imgFrame" is, really, is a surface with some additional behavior (automatic storage in volatile buffers when possible, optimization of single-color images, support for padding, etc.) that's specific to images. Bug 1054079 highlights this confusion because it makes imagelib's SurfaceCache actually store imgFrame objects. This makes total technical sense, but the confusion between the "frame" and "surface" terminology is grating. Another argument against using "imgFrame" is that most Gecko code that refers to 'frames' is referring to a layout concept, not an imagelib concept. nsImageFrame exists and is a totally different thing! It's clear that the name "imgFrame" was chosen when thinking of animated images, but I think this terminology is best reserved for a higher-level class that actually deals with animation. A RasterImage may contain a sequence of frames, but it seems reasonable that the type of each frame should actually be some sort of "surface". TLDR; I propose renaming "imgFrame" to "ImageSurface".
Summary: Rename 'imgFrame' to something more consistent with the rest of our code → Rename 'imgFrame' to 'ImageSurface'
Seth, you said there are two "value adds" for an imgFrame: 1) lifecycle management from an in-memory surface (i.e. a DataSourceSurface) to some form of optimized surface once we finish decoding 2) animation-related stuff and that both of these are going away. Do you have bug numbers or more info about how these things are going away?
You need to log in before you can comment on or make changes to this bug.