[webkit-dev] HbbTV support within Webkit
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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote: 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. For reference, here is a link to the previous thread: https://lists.webkit.org/pipermail/webkit-dev/2011-June/017195.html --Martin ___ 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
Hey, can you share your plan how to prioritize network requests in the network process? It's a long standing issue of the chromium port (and I believe the blackberry port is affected as well) that a ResourceRequest doesn't know whether it was created for e.g. an XHR or a main document load, which makes it difficult to prioritize the requests. We currently work around that issue by adding a TargetType to ResourceRequest which is however a layering violation which I'd like to get rid of. best -jochen On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ 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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? Adam On Mon, Oct 8, 2012 at 10:39 AM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ 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
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.comwrote: ** I'd like to ask the Webkit developers their opinion on providing some support for HbbTV [1] within Webkit. By some support, what exactly do you mean? 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. ** It also burdens other contributors who refactor and maintain that code. WML was a mess and imposed a significant maintenance cost on everyone who worked on script and input elements. 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. I have a hard time understanding the exact requirement for supporting CE-HTML and HbbTV. What kind of changes do you want to make to the trunk WebKit? 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. Making WebKit more pluggable to support CE-HTML and HbbTV sound good to me as long as it doesn't significantly increase the maintenance burden on contributors. - Ryosuke ___ 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 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Thanks, ~Brady Adam On Mon, Oct 8, 2012 at 10:39 AM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ 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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 8, 2012, at 10:52 AM, Jochen Eisinger joc...@chromium.org wrote: Hey, can you share your plan how to prioritize network requests in the network process? … We currently work around that issue by adding a TargetType to ResourceRequest which is however a layering violation which I'd like to get rid of. Since the NetworkProcess management will be contained in WebKit 2 it won't be an equivalent layering violation for that port. If that explanation doesn't make sense then I might have misinterpreted your concern. On a slightly different note it seems reasonable to me that a WebCore ResourceRequest have target-type/priority-type information attached to it. I don't know if doing that has come up in the past and different conclusions we reached. I haven't placed a lot of thought into that since it doesn't seem directly necessary for this effort. ~Brady best -jochen On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote: A bit of background: A few of us have been working on enhancing WebKit2's support for multiple WebProcesses. As part of this effort I'm working on https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to WebKit2 One benefit of the NetworkProcess will be to have a single shared process doing network i/o on behalf of all attached WebProcesses. Another benefit we've identified is the ability to have that process also act as custodian for a shared memory cache amongst the attached WebProcesses. While this effort is primarily about WebKit 2, making it possible will obviously involve some changes to the WebCore memory cache and resource loading. I don't plan to shoehorn in changes, but rather to make sensical refactoring that cleans up the code for all ports. Anyone familiar with the CachedResource and ResourceLoader mechanisms probably know they're not really up to the clarity and quality standards we strive for, and I'm excited about being able to focus on them for awhile and make them better for everyone. I have a few patches lined up locally to do this and have attached the first of these to https://bugs.webkit.org/show_bug.cgi?id=98539 Feel free to share concerns here or in the collection of bugzillas that will slowly be growing as I make progress. ~Brady ___ 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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Without data showing that this is a win, adding a shared memory cache to WebCore seems like over-engineering and unneeded complexity. We had the same design instincts as you when we looked at this issue in Chromium, but we studied the issue (twice actually) and concluded that the complexity wasn't worth the meager benefits. Adam ___ 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
08.10.2012, в 11:23, Brady Eidson beid...@apple.com написал(а): On a slightly different note it seems reasonable to me that a WebCore ResourceRequest have target-type/priority-type information attached to it. I don't know if doing that has come up in the past and different conclusions we reached. I haven't placed a lot of thought into that since it doesn't seem directly necessary for this effort. ResourceRequest is a network level concept, so making it know about whether it loads a stylesheet, a script or an XHR is clearly a layering violation. Giving it some kind of generic priority is not, on the other hand. Anyway, as Brady mentioned, this is not related to this refactoring. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Without data showing that this is a win, adding a shared memory cache to WebCore seems like over-engineering and unneeded complexity. We had the same design instincts as you when we looked at this issue in Chromium, but we studied the issue (twice actually) and concluded that the complexity wasn't worth the meager benefits. There might be some misunderstanding of the specifics of what I'm working on. I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of shared memory directly to WebCore. I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2. Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients. I'm not sure that I see how this case is in a different category. Thanks, ~Brady Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Exclusions: Implementing shape-outside for floats (bug 98664)
Hi all, We've been working on implementing the CSS Exclusions Spec (http://dev.w3.org/csswg/css3-exclusions/) here at Adobe. As part of that effort, I am beginning work on implementing support for shape-outside (http://dev.w3.org/csswg/css3-exclusions/#shape-outside-property) on floats (http://dev.w3.org/csswg/css3-exclusions/#floats-and-exclusions). I have filed bug 98664 to track this work. I'm sending out this mail just as a heads up and to see if anyone has any questions, concerns, comments, or problems with respect to this. Thanks, Bem ___ 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 Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Without data showing that this is a win, adding a shared memory cache to WebCore seems like over-engineering and unneeded complexity. We had the same design instincts as you when we looked at this issue in Chromium, but we studied the issue (twice actually) and concluded that the complexity wasn't worth the meager benefits. There might be some misunderstanding of the specifics of what I'm working on. I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of shared memory directly to WebCore. I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2. Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients. I'm not sure that I see how this case is in a different category. Would there be any design or implementation constraints on WebCore? For example, would WebCore need to understand any concurrency or performance issues caused by the memory being shared between processes? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING to WebCore
Hi webkit-dev, I wanted to let you know that I plan to add a feature to support throttling of DOM timers on hidden pages to WebKit. This support will be hidden behind the ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define. See: https://bugs.webkit.org/show_bug.cgi?id=98474 The way it works is to make DOM timers on pages whose visibility is set to hidden, fire only at times that are even multiples of a specified alignment interval, currently set to 1 second. This aligning of timers differentiates it from the existing mechanism for throttling, namely increasing the minimum timer interval. Further, alignment is not subject to the ramp-up behavior of minimum timer interval, where the first five times of a repeating timer or a chained series of one-shot timers get no clamping. This feature is not yet fully backed and it has a risk of compatibility issues. A known issue at this time is that pages that use timers to schedule WebAudio playback instead of events will have breaks in audio output. For instance http://chromium.googlecode.com/svn/trunk/samples/audio/shiny-drum-machine.html. Putting this behind a feature define will allow each port to decide if they are interested and enable it individually. Enabling it on more ports would help us better test this feature and we appreciate any help we can get. We will be enabling this feature on Mac and hence it will be tested by the existing Mac buildbots. Looking forward to your feedback. - Kiran ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: WTF HashMap iterators to use key/value instead first/second
Hello, Follow up: this change landed in http://trac.webkit.org/changeset/130612. Cheers, -- Caio Marcelo de Oliveira Filho openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ 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 8, 2012, at 12:17 PM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Without data showing that this is a win, adding a shared memory cache to WebCore seems like over-engineering and unneeded complexity. We had the same design instincts as you when we looked at this issue in Chromium, but we studied the issue (twice actually) and concluded that the complexity wasn't worth the meager benefits. There might be some misunderstanding of the specifics of what I'm working on. I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of shared memory directly to WebCore. I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2. Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients. I'm not sure that I see how this case is in a different category. Would there be any design or implementation constraints on WebCore? For example, would WebCore need to understand any concurrency or performance issues caused by the memory being shared between processes? For now we think the answer is no, or that any parts that do need to be concerned to be wholly encapsulated within the support for the client model. Thanks, ~Brady Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congratulations Caio! :-) Regards, Rafael On Mon, Oct 8, 2012 at 6:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Rafael Brandao @ INdT ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congratulations, Caio! On Mon, Oct 8, 2012 at 2:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ 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] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congrats! On Mon, Oct 8, 2012 at 11:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ 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
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congrats! On Mon, Oct 8, 2012 at 6:44 PM, Alexis Menard men...@kde.org wrote: Congrats! On Mon, Oct 8, 2012 at 6:27 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Congrats! On Mon, Oct 8, 2012 at 11:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Congratulations Caio! :D On Mon, Oct 8, 2012 at 5:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
Adding support for custom variants of HTML is not really in line with the goals of the WebKit project. It sounds like CE-HTML and OIPF are both HTML variants. I don't think these types of features are a good fit for WebKit, because: (1) Custom HTML dialects tend to create excessive maintenance burden for the contributors who are not interested in the feature. WAP is a historical example. We much prefer features that either have broad mainstream interest, or at the very least can be implemented with minimal intrusion into core code. (2) Most contributors to the WebKit project strongly believe in a One Web vision, where the same full core specifications are used in all the contexts where Web technology is useful - no special dialects for mobile, or tv, or whatever, it's all one web. Custom HTML dialects go against that vision, so the value of adding support would have to be very high to even consider it. I strongly recommend that the HbbTV effort should use HTML5 and other Web technologies directly, rather than profiling and extending the Web. Regards, Maciej On 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] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 12:17 PM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote: When we looked at whether we should add a shared memory cache to Chromium, we came to the conclusion that there wasn't much benefit to having a shared memory cache. In https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that you have data showing that a shared memory cache is a win. Would you be willing to share this data with the WebKit community? It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring. WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on. We don't have hard data to share at this time. A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them. Without data showing that this is a win, adding a shared memory cache to WebCore seems like over-engineering and unneeded complexity. We had the same design instincts as you when we looked at this issue in Chromium, but we studied the issue (twice actually) and concluded that the complexity wasn't worth the meager benefits. There might be some misunderstanding of the specifics of what I'm working on. I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of shared memory directly to WebCore. I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2. Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients. I'm not sure that I see how this case is in a different category. Would there be any design or implementation constraints on WebCore? For example, would WebCore need to understand any concurrency or performance issues caused by the memory being shared between processes? For now we think the answer is no, or that any parts that do need to be concerned to be wholly encapsulated within the support for the client model. Ok. If there are no design implications for WebCore, then I don't have a problem with this work continuing. Based on my experience with this topic in Chromium, I believe you're over-engineering, but if you're unwilling to share your data, I doubt further discussion with cause either of us to change our minds. Adam ___ 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 8, 2012, at 5:28 PM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson beid...@apple.com wrote: On Oct 8, 2012, at 12:17 PM, Adam Barth aba...@webkit.org wrote: Would there be any design or implementation constraints on WebCore? For example, would WebCore need to understand any concurrency or performance issues caused by the memory being shared between processes? For now we think the answer is no, or that any parts that do need to be concerned to be wholly encapsulated within the support for the client model. Ok. If there are no design implications for WebCore, then I don't have a problem with this work continuing. Based on my experience with this topic in Chromium, I believe you're over-engineering, but if you're unwilling to share your data, I doubt further discussion with cause either of us to change our minds. Hi Adam, You can expect that we'll collect and share some data as the work progresses. The fact is that we don't have really great data to share yet, we are still in an exploratory phase. If you have any past data to share, we'd love to look at it. One preliminary finding of ours is that different web pages fairly often load identical resource bodies from different URLs. We expect possible benefits from sharing the body data of resources in memory even if we cannot share the URL or response headers. You can also expect that we won't push forward blindly on this effort if data ultimately shows it to be a bad idea, or in general not worth the complexity. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho
Cool! Congratulations Caio! On Mon, Oct 8, 2012 at 2:20 PM, noam.rosent...@nokia.com wrote: I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer. Caio has been working in many areas in the past years, starting with focus on the Qt port with improvements to the Qt/JS bridge, font test results and render-theme. More recently has also work on the UndoManager and other aspects of editing code and CSS parsing, his latest contributions being around WTF HashMap iterators. Since Caio has been involved in so many parts of WebKit, I'm probably forgetting a few other contributions... Please join me in congratulating Caio for his new reviewer status! No'am ___ 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
