Re: [webkit-dev] HbbTV support within Webkit
Hi, HbbTV and OIPF specifications are available to download from the HbbTV and OIPF sites: http://www.hbbtv.org/pages/about_hbbtv/specification.php http://www.oipf.tv/specifications The closed standard is the CE-HTML standard, which is referenced by OIPF. The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of W3C standards and the AV Control plugin. We're currently looking at our changes to identify areas that can be delivered back which can provide benefit to Webkit without causing any additional maintenance overhead. What we would like to see initially is Webkit based browsers (Chrome, Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the user to download the content - this would indirectly benefit the end goal of Webkit (to get everyone to support standard W3C/HTML5)... As you can imagine, most application authors are web developers, and do not necessarily have experience with HbbTV, OIPF or CE-HTML, so they use the standard W3C/HTML5/XHTML constructs they are familiar with, except for the TV specific API's or plugins. More often than not, they'll write their application so that it can also run on a PC browser, because they have far better debugging facilities than TVs! However, as soon as the application is signalled correctly with an HbbTV or CE-HTML mime type, most browsers then just ask to download the page. Also, many test with a browser in 'HTML' mode, and not the stricter 'XHTML' mode. Regards, Mark. -Original Message- From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth Sent: 08 October 2012 19:36 To: Mark Toller Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] HbbTV support within Webkit From your message, it sounds like HbbTV is still not an open standard. I'm skeptical that we should support closed standards in WebKit. Adam On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote: Hi, I'd like to ask the Webkit developers their opinion on providing some support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or HbbTV, is a major new pan-European initiative aimed at harmonising the broadcast and broadband delivery of entertainment to the end consumer through connected TVs and set-top boxes. The HbbTV standard is proving to be very popular, TVs and STBs supporting HbbTV are shipping in huge numbers throughout Europe. HbbTV is built on top of OIPF [2], which in turn is based on portions of CE-HTML [3]. Our lab, Samsung Electronics Research Institute (SERI), has been heavily involved in HbbTV and our current solution is based on Webkit. We would like to provide our changes back to the community. I know that support requests for CE-HTML have been briefly touched upon in the past. As I understand it, the main objection to providing support within WebKit is that the CE-HTML specification is not freely available, and thus restricts the number of developers who can fully understand it and therefore provide fixes / support. In reality, much of the CE-HTML specification simply profiles which parts of the W3C standard behaviour are mandatory, optional and/or recommended. OIPF then profiles CE-HTML (dropping some requirements, extending others to match W3C/HTML5), HbbTV profiles out even more of CE-HTML. Other parts of OIPF and CE-HTML do not need to be implemented within Webkit itself. Some can be implemented as object plugins (e.g. AV Control and local video), while others, such as the JavaScript classes required, can be inserted into the JavaScriptCore at runtime. What I propose is to provide the basic support required within Webkit in order to at least load the XHTML portions of HbbTV applications and provide the correct key handling to drive them. In order to provide 'full' HbbTV support, implementations would need to provide the plugins and additional JavaScript classes to complete the picture. For instance, by simply adding support for the document mime type handling of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV applications will load and display the main page, and several will also correctly navigate around the application correctly. Regards, Mark. [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/ [2] Open IPTV Forum - http://www.oipf.tv/ [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
Hi, I still don't get it. CE-HTML is a closed standard and not something we ever want in WebKit as we are pushing HTML5/Living Standard. I understand that you need some execution and security model, but apart from that I don't see why you don't aim at supporting HTML5 instead of some custom dialect that is moving in another direction that they rest of the industry. Even with the System Applications working group [1], which Samsung is co-chairing, the execution and security model will get solved with proper participation. Also the need for using XHTML isn't that big anymore, now that HTML5 defines how to actually parse the document. Cheers Kenneth [1] http://www.w3.org/2012/05/sysapps-wg-charter.html On Wed, Oct 10, 2012 at 9:26 AM, Mark Toller mark.tol...@samsung.com wrote: Hi, HbbTV and OIPF specifications are available to download from the HbbTV and OIPF sites: http://www.hbbtv.org/pages/about_hbbtv/specification.php http://www.oipf.tv/specifications The closed standard is the CE-HTML standard, which is referenced by OIPF. The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of W3C standards and the AV Control plugin. We're currently looking at our changes to identify areas that can be delivered back which can provide benefit to Webkit without causing any additional maintenance overhead. What we would like to see initially is Webkit based browsers (Chrome, Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the user to download the content - this would indirectly benefit the end goal of Webkit (to get everyone to support standard W3C/HTML5)... As you can imagine, most application authors are web developers, and do not necessarily have experience with HbbTV, OIPF or CE-HTML, so they use the standard W3C/HTML5/XHTML constructs they are familiar with, except for the TV specific API's or plugins. More often than not, they'll write their application so that it can also run on a PC browser, because they have far better debugging facilities than TVs! However, as soon as the application is signalled correctly with an HbbTV or CE-HTML mime type, most browsers then just ask to download the page. Also, many test with a browser in 'HTML' mode, and not the stricter 'XHTML' mode. Regards, Mark. -Original Message- From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth Sent: 08 October 2012 19:36 To: Mark Toller Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] HbbTV support within Webkit From your message, it sounds like HbbTV is still not an open standard. I'm skeptical that we should support closed standards in WebKit. Adam On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote: Hi, I'd like to ask the Webkit developers their opinion on providing some support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or HbbTV, is a major new pan-European initiative aimed at harmonising the broadcast and broadband delivery of entertainment to the end consumer through connected TVs and set-top boxes. The HbbTV standard is proving to be very popular, TVs and STBs supporting HbbTV are shipping in huge numbers throughout Europe. HbbTV is built on top of OIPF [2], which in turn is based on portions of CE-HTML [3]. Our lab, Samsung Electronics Research Institute (SERI), has been heavily involved in HbbTV and our current solution is based on Webkit. We would like to provide our changes back to the community. I know that support requests for CE-HTML have been briefly touched upon in the past. As I understand it, the main objection to providing support within WebKit is that the CE-HTML specification is not freely available, and thus restricts the number of developers who can fully understand it and therefore provide fixes / support. In reality, much of the CE-HTML specification simply profiles which parts of the W3C standard behaviour are mandatory, optional and/or recommended. OIPF then profiles CE-HTML (dropping some requirements, extending others to match W3C/HTML5), HbbTV profiles out even more of CE-HTML. Other parts of OIPF and CE-HTML do not need to be implemented within Webkit itself. Some can be implemented as object plugins (e.g. AV Control and local video), while others, such as the JavaScript classes required, can be inserted into the JavaScriptCore at runtime. What I propose is to provide the basic support required within Webkit in order to at least load the XHTML portions of HbbTV applications and provide the correct key handling to drive them. In order to provide 'full' HbbTV support, implementations would need to provide the plugins and additional JavaScript classes to complete the picture. For instance, by simply adding support for the document mime type handling of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV applications will load and display the main page, and several
Re: [webkit-dev] HbbTV support within Webkit
On Wed, Oct 10, 2012 at 3:50 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Hi, I still don't get it. CE-HTML is a closed standard and not something we ever want in WebKit as we are pushing HTML5/Living Standard. Just to provide some additional input. CE-HMTL, more formally known as CEA-2014, is *not* a closed standard. It is available to anyone who wishes to pay CEA for a copy. In that respect, it is no different from ISO/ITU standards that sometimes cost money to obtain a copy. I understand that you need some execution and security model, but apart from that I don't see why you don't aim at supporting HTML5 instead of some custom dialect that is moving in another direction that they rest of the industry. Even with the System Applications working group [1], which Samsung is co-chairing, the execution and security model will get solved with proper participation. Also the need for using XHTML isn't that big anymore, now that HTML5 defines how to actually parse the document. Rather than delving deeper into this proposal, I would suggest the original commenter should make some very specific technical proposals (accompanied by actual patches) that may satisfy his requirements, instead of simply propose support for the higher level notion of this profile. The merit of such individual technical proposals (patches) can be evaluated on a case by case basis, as is the case with other features proposed for addition to WK. Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] x32 support of JavaScriptCore
Hi, As you may already know there's a new x32 ABI - a 32-bit psABI for x86-64 with 32-bit pointer size. It tries to leverage the advantage of more registers and IP relative addressing from x64 and the advantage of smaller memory footprint from IA32. You can find more details of the x32 ABI here: https://sites.google.com/site/x32abi/. The Linux kernel supports x32 since 3.4, and the commonly used development tools and libraries are getting in the x32 support. Also more details about current status is available in the above link. Now back to WebKit. In theory most part of the WebKit code should be fine (or require less efforts) to support x32, if they're pure C++ code and can be compiled with the x32 toolchain. The major challenge is the JIT compiler in the JavaScript engine (and the low level interpreter) and some hand-written assembly code. So I'm currently working on enabling the x32 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove the major obstacle. My current status is that I have enabled the baseline JIT, the DFG JIT and the Yarr JIT on x32 - it passes all the JavaScriptCore tests and the 3 major benchmarks. I'm posting this message in order to seek for some advices on how we should have our work shared to more people. I understand that it's not very appropriate to try to get it into current WebKit trunk considering current x32 support status in major systems and the lack of maintenance in upstream, but we want to keep it synchronized with the newest changes of the WebKit code. So is it possible for us to maintain the code in a separate branch hosted at the WebKit server? Any suggestions are appreciated. Thanks, -Yuqiang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 1:50 PM, Adam Barth aba...@webkit.org wrote: That raises the question of what the cache-size to hit-rate curve looks like. I don't think that's something we've ever measured for the MemoryCache, but it would be interesting to know, for example, whether increasing the cache size by 4% increases the cache hit rate by more or less than 4%. My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. The question you raise is ceratainly an interesting one to study to determine the optimum cache size, and to revisit when improvements are made to cache efficiency. But with respect to the proposed improvement under discussion: If you imagine this as a curve with hit rate on the Y axis and cache size required to achieve that hit rate on the X axis, then the potential improvement under discussion would shift the curve down (assuming the 4% redundancy level holds across the typical user's working set). In economic terms, you can think of this as shifting the supply curve down (more hit rate can be supplied at any given cost in memory), rather than movement along the supply curve. Which is pretty good for you regardless of your demand curve (your willingness to pay memory use for cache hit rate). Yes, but depending on the slope of the curve, you can be introducing all this complexity for, e.g., a 1% increase in the cache hit rate. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Transformations precision: double - float
Hello! That was a long time ago and there were no objections so I made a bug for the further discussions and patches: https://bugs.webkit.org/show_bug.cgi?id=98913 Regards, Gabor What CPU executes single precision floating point values at the same speed as double precision? Here's a benchmark from NASA giving a comparison of single vs. double precision performance for one of their simulations. https://modelingguru.nasa.gov/docs/DOC-1664. Single precision maps better to GPU backends, and CPU's SIMD computations than double. Unless there's something in the spec requiring double precision it makes sense to move away from double precision throughout WebKit. It's fairly trivial to make SIMD types that can have CPU architecture specific implementations. As an example of how to do this in the wild there's the Sony vectormath library that's present in the Bullet Physics Library. http://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/vectormathlibrary/include/vectormath/. As Kui noted the TransformationMatrix is a hotspot that could be helped by SIMD. Making the solution generic enough to target multiple architectures using SIMD should help the performance on all the platforms. Don -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Simon Fraser Sent: Monday, May 21, 2012 10:35 AM To: Zoltan Herczeg Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Transformations precision: double - float TransformationMatrix started out as floats, then got changed to doubles in http://trac.webkit.org/changeset/40761 This was done because on most hardware there is no penalty for using doubles over floats, and provided a better match with our system APIs that used doubles. I'd prefer to take a forward-looking stance here, and assume that in time hardware will catch up. Simon On May 21, 2012, at 4:04 AM, Zoltan Herczeg wrote: Hi, is there any reason why the transformations in WebKit use doubles? We could optimize some functions further with ARM SIMD if they would be floats. Is there any objection to make them float if the change would have no other side effects except some rounding because of the lower precision? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 10, 2012, at 8:49 AM, Adam Barth aba...@webkit.org wrote: On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 1:50 PM, Adam Barth aba...@webkit.org wrote: That raises the question of what the cache-size to hit-rate curve looks like. I don't think that's something we've ever measured for the MemoryCache, but it would be interesting to know, for example, whether increasing the cache size by 4% increases the cache hit rate by more or less than 4%. My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. The question you raise is ceratainly an interesting one to study to determine the optimum cache size, and to revisit when improvements are made to cache efficiency. But with respect to the proposed improvement under discussion: If you imagine this as a curve with hit rate on the Y axis and cache size required to achieve that hit rate on the X axis, then the potential improvement under discussion would shift the curve down (assuming the 4% redundancy level holds across the typical user's working set). In economic terms, you can think of this as shifting the supply curve down (more hit rate can be supplied at any given cost in memory), rather than movement along the supply curve. Which is pretty good for you regardless of your demand curve (your willingness to pay memory use for cache hit rate). Yes, but depending on the slope of the curve, you can be introducing all this complexity for, e.g., a 1% increase in the cache hit rate. If that's the slope, and someone (e.g. a vendor) doesn't like that tradeoff, they could take a 4% reduction in the cache size instead. (The curve is almost surely nonlinear so we're really talking about marginal slope at a given pre-existing cache size.) That's what I meant about shifting the curve down. It only fails to be worth it if neither a 4% reduction in the memory used by the cache nor the equivalent hit rate improvement nor any combination in between are worth it. The availability of the speed tradeoff can't make the change less worthwhile than if it was just a straight memory use reduction. I would be highly surprised if anyone sincerely finds it not worth it on either basis, particularly in case of vendors who target mobile devices with limited memory. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
My guess is that frequency of hits on given cache items approximately follows a power law distribution, and therefore increasing cache size gives diminishing returns. FWIW, a few years back I did some in-depth data gathering on this score using real world websites. I found that, for encoded data, hit rate in the cache increased exponentially as cache size increased up to ~4MB, increased linearly as cache size increased above ~4MB, and increased not at all as cache size increased above ~100MB (since all resources that were eligible for caching and not expired were already in the cache). My guess is that the inflection points in the graph have moved out to ~8MB or ~16MB in the past few years. Note that these numbers do not correspond precisely to WebCore cache sizes, since the WebCore cache size includes both encoded and decoded data. Of course, the precise hit rates you'll see depend on the content you're browsing, and it's possible to hand-craft content that shows benefits up to arbitrarily large cache sizes, or shows no benefits down to arbitrarily small cache sizes. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
Hi, I don't think another branch on webkit.org will help you much; then you can as well have a branch anywhere. If you want this code to be well tested and maintained, you need to get it upstream (through all the review process) and promise that you have resources to keep maintaining it. It will also be an advantage if we can get a buildbot running this exact configuration, so that others can make sure they don't break your code. I think that whether the community will accept it upstream depends much about your commitment and the quality of the code, as well as how well you interact with the community during the reviews. Which port of WebKit is you currently using for testing? Cheers Kenneth On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote: Hi, As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64 with 32-bit pointer size. It tries to leverage the advantage of more registers and IP relative addressing from x64 and the advantage of smaller memory footprint from IA32. You can find more details of the x32 ABI here: https://sites.google.com/site/x32abi/. The Linux kernel supports x32 since 3.4, and the commonly used development tools and libraries are getting in the x32 support. Also more details about current status is available in the above link. Now back to WebKit. In theory most part of the WebKit code should be fine (or require less efforts) to support x32, if they’re pure C++ code and can be compiled with the x32 toolchain. The major challenge is the JIT compiler in the JavaScript engine (and the low level interpreter) and some hand-written assembly code. So I’m currently working on enabling the x32 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove the major obstacle. My current status is that I have enabled the baseline JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore tests and the 3 major benchmarks. I’m posting this message in order to seek for some advices on how we should have our work shared to more people. I understand that it’s not very appropriate to try to get it into current WebKit trunk considering current x32 support status in major systems and the lack of maintenance in upstream, but we want to keep it synchronized with the newest changes of the WebKit code. So is it possible for us to maintain the code in a separate branch hosted at the WebKit server? Any suggestions are appreciated. Thanks, -Yuqiang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
