On 17 December 2014 at 09:43, Seth Fowler <s...@mozilla.com> wrote: > > Right now, ImageLib provides very general support for > multipart/x-mixed-replace images. Each part may contain a different image > format (we may even switch between raster and vector images from one part > to the next), individual parts may be animated, and each part may have a > different size. > > This has major costs for us. Supporting existing images changing their > size requires that layout and content code be aware of > multipart/x-mixed-replace images, and requires us to use a design that’s > suboptimal for the common case of MJPEG webcam content. Because these > changes in size, type, and animation state prevent many invariants we’d > like to have in ImageLib from holding, we either can’t assert some things > we’d like to assert, or the assertions are quite tricky to write, which > leads to more bugs and more maintenance headaches. There’s also just more > and uglier code to maintain: over time hacks to multipart/x-mixed-replace > have popped up in many places in Gecko, inside and outside ImageLib, and > I’d like to remove them. And despite all of this effort, it’s not clear to > me that our support is actually very robust, because outside of our limited > test suite as far as I can tell nobody uses multipart/x-mixed-replace > images for anything except MJPEG! > > I’ve had to change how multipart/x-mixed-replace is implemented in > ImageLib to support other, more important, features. As part of this > refactoring, I plan to pare down our support to the minimum required for > MJPEG webcams: > > (1) The individual parts may only be JPEG images. Other formats will not > be supported. > (2) All of the parts must have the same intrinsic size as the first part - > in other words, size changes will not be supported. > > In case it’s not clear, there’ll be no effect on other uses of > multipart/x-mixed-replace elsewhere in the browser. These changes are > specific to images and ImageLib. > > Making these changes will allow me to totally encapsulate MJPEG support > inside ImageLib. Other code will see an MJPEG as just another type of > animated image. Virtually all of the ugly consequences of our current > multipart/x-mixed-replace image support will fall away. > > If anyone has any concerns about this change, please let me know. We > should be fairly safe in doing this since non-MJPEG > multipart/x-mixed-replace images are essentially never used, and > multipart/x-mixed-replace itself is not universally supported anyway - IE > does not even support MJPEG, much less the more general features that we > provide. There also does not seem to be any specification that requires > support for multipart/x-mixed-replace images at all, although HTML5 does > specify multipart/x-mixed-replace support for documents. > > Thanks, > - Seth > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform >
Sounds reasonable, a few questions: * Is there telemetry for this? * I'm assuming this is for all of <img>, <object>, top level documents (and css src()? was that ever supported?) * What is the end user experience? * In the case of differing formats - The first image displaying and then a broken image icon? * Differing dimensions - image is scaled to first image's dimensions? Are scaling CSS hints (aspect, interpolation mode) applied? I can imagine at least a small "loading" first frame might be sent followed by actual camera images. -- James _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
