El mié, 01-04-2015 a las 15:24 +0900, ChangSeok Oh escribió: [...] > > FAQ > 1. We already have WebP. Do we need to support other image format? > We had png, but it does not mean we can drop jpg support. We had apng, > but we can’t drop gif support. > In same manner, I think supporting any other format could not be a > reason to reject jxr support.
I agree, the fact that we support other formats is not a reason not to support new ones. > > 2. Is there any advance from WebP? > This is pretty debatable topic. You can see a lot of discussions > happened regarding this if you google ‘jpeg-xr v.s webp’ like that. > I think extending the argument here is not productive. jpeg-xr has its > own advances so I think supporting webp is out of consideration to > adopt jpeg-xr. It doesn't matter which format is better or worse, what matters to us is the compatibility. We need to support whatever the web sites use. > > 3. Chromium and mozilla rejected jpeg-xr support. > Yeah I know. I’m the guy proposing jpeg-xr support to blink. I can > understand their stance since webp is owned by google and they're > driving webp as a next modern image standard. But is there any reason > for WebKit to follow google’s stance? Especially for WebKitGTK+, we > support WebP, but it’s not supported by Gecko nor IE. We supports > apng, but it’s not supported by Chromium nor IE. In same manner, there > is no reason not to support jpeg-xr I think. I see this as an advantage, TBH. Supporting things other don't, makes us stronger :-) > > 4. How popular is it in web? > I have not much information on this. (Maybe flickr, tumblr, adobe > flash player? I’m not sure) But this question is something similar to > the question, what comes first, chicken or egg.. > jpeg-xr can’t spread out in the world because of browser > compatibility. That’s what content author complain about both webp and > jpeg-xr. > For the reason, I think measuring the popularity of new image format > is meaningless. Personally I don’t think how chromium could adopt webp > is not because of its popularity in the web. This is the key point in my opinion. Adding more code to support something nobody is using ... It also depends how easy to maintain the code is. I mean, if most of the work is done by the external library and we only need a few lines of code to support that (and it's optional dep), it would make sense. Unfortunately that's not the case of all other image formats, even if we use libjpeg, libpng, etc., the glue code to use that in WebKit is a lot, and not trivial code. Another negative point I see, is that the external library is not adopted by distros, and it seems upstream support sucks (no serious build system, no public repo nor download link, etc.) > > BR. > > > [1] https://bugs.webkit.org/show_bug.cgi?id=143265 > [2] https://lists.webkit.org/pipermail/webkit-dev/2015-March/027325.html > [3] http://en.wikipedia.org/wiki/JPEG_XR#Licensing > [4] http://www.itu.int/rec/T-REC-T.832 > [5] https://code.google.com/p/chromium/issues/detail?id=56908#c17 > [6] http://blog.kaourantin.net/?p=116 > > ChangSeok > > > _______________________________________________ > webkit-gtk mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
