Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
On Friday 2015-01-02 14:23 +0100, Robert Kaiser wrote: Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
L. David Baron schrieb: On Friday 2015-01-02 14:23 +0100, Robert Kaiser wrote: Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. We have been burned by removing Gecko-only features in JS land, that's why even that reasoning is dangerous in general. For this specific case everything might be fine, I don't dispute that, but we shouldn't do removals of web-exposed features without good data in general. Can we at least have a very small telemetry probe along with this specific removal (can be removed in the next train again), so we can get at least some data from beta users if there are cases encountered of those features we remove? I'd have guessed we all, including Seth, would be happier if we have data confirmation of us doing the right thing here. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
I'd say this is far enough out towards extreme edge case land that we can be a bit more aggressive here compared to general feature removals. So agreed. On Fri, Jan 2, 2015 at 1:52 PM, Seth Fowler s...@mozilla.com wrote: On Jan 2, 2015, at 7:16 AM, L. David Baron dba...@dbaron.org wrote: IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. That is true. IE does not support this feature at all. I completely concur that in general we should gather telemetry before removing a feature that’s exposed to the web, but I just don’t see it as adding much value for this *particular* case. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- jst ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
On Jan 2, 2015, at 7:16 AM, L. David Baron dba...@dbaron.org wrote: IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. That is true. IE does not support this feature at all. I completely concur that in general we should gather telemetry before removing a feature that’s exposed to the web, but I just don’t see it as adding much value for this *particular* case. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
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
PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
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
