[webkit-dev] Feature Proposal: Implement Stream and StreamReader
Hi webkit-dev! I'm currently working on adding support for Stream and StreamReader to WebKit. https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This support will be behind the ENABLE_STREAM feature define. I have a prototype which implements readAsArrayBuffer() from an XHR connection at: https://bugs.webkit.org/show_bug.cgi?id=110194 Tests will be added as I change it to a real implementation. Cheers, -Zach ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
The purpose of the NodeTraversal refactoring was simply to move the existing traversal functions off the (rather bloated) Node and add Element specific functions. I think longer term iterators are the way to go as they allow decoupling our internal document tree data structures from the DOM API. The problem with ComposedShadowTreeWalker is not that it is an iterator but that it is ill-defined and complex. It calls back to non-trivial, mutating functions on the structure being traversed (ContentDistributor::distribute!). Simply traversing a tree with it can apparently end up marking the tree for style recalc. I don't think adding NodeRenderingTraversal on top of this helped much though it did clarify the case where ComposedShadowTreeWalker is actually needed. antti On Tue, Feb 19, 2013 at 4:18 AM, Hajime Morrita morr...@chromium.orgwrote: AncestorChainWalker follows the style of ComposedShadowTreeWalker, which also breaks conventions like mutations-should-be-verbs. We also fix its style for integrity. Non-trivial tree traversal API in general should, IMO, be modeled after recently introduced NodeTraversal. Having separate namespaces allows us to keep Node API minimal. Also it is stateless and simple. I made NodeRenderingTraversal in that way. AncestorChainWalker could be just merged to NodeRenderingTraversal. Speaking of ComposedShadowTreeWalker, I think it is worth having a class instead of namespace since it holds configuration parameters to decide, for example, whether it skips specific types of node. On Tue, Feb 19, 2013 at 10:37 AM, Darin Adler da...@apple.com wrote: I am trying to learn about code related to shadow DOM that needs to be understood by anyone working on an part of the DOM. I have some questions and concerns about AncestorChainWalker. If there is a document I should be reading that covers these, please point me to it. The parentNode and parentElement functions are just plain old functions that are used to walk the ancestor chain of the normal DOM. But the shadow DOM AncestorChainWalker is a class. Why? It seems that it could just be a function with two return values. Is it more efficient to have it be a class? Can the operation be correctly done without storing m_distributedNode in a data member? There is a function in AncestorChainWalker named parent. That name is a noun, so the function should be a const function that returns a value. Since it’s not, the function name should be a verb phrase, such as advanceToParent, or event just “advance” since it’s in the context of an ancestor chain walker. The function crossingInsertionPoint should be named isCrossingInsertionPoint as the data member is. But also, since the walker sits still on a single node, I don’t think it makes sense to talk about the position as “is crossing”. It should be “just crossed” or something like that instead. Unless an insertion point is like a bridge and is not itself a “true node”. The function that returns the current node in the ancestor chain is named “get”. That’s not a good name, and should be avoided if possible. It could be named “node” or “currentNode” instead. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto koivi...@iki.fi wrote: The problem with ComposedShadowTreeWalker is not that it is an iterator but that it is ill-defined and complex. It calls back to non-trivial, mutating functions on the structure being traversed (ContentDistributor::distribute!). Simply traversing a tree with it can apparently end up marking the tree for style recalc. This is a really good point. It encapsulates traversal of the composed tree, but this tree's integrity is maintained lazily, which means that as you traverse it, you could force the update. That ain't awesome. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Getting involved
Hi Jason, On http://trac.webkit.org/wiki there are a bunch of pages under Layout Tests and Performance Tests that describe much of the infrastructure. These days most of it is written in Python. I don't know what projects Benjamin has in mind so I don't know if that will match what he was referring to, but hopefully this will be helpful. -- Dirk On Mon, Feb 18, 2013 at 3:44 PM, Jason Anderssen janders...@exactal.com wrote: Hello Benjamin, Thank you for a starting point and would like to explore further with this. Please point me in the right direction to how I can help in the cleaning of the WebKit testing infrastructure please. This will also allow me to understand how all you guys work together and understand the procedures etc.. Cheers Jason From: Benjamin Poulain benja...@webkit.org Date: Tue, 19 Feb 2013 08:52:17 +1000 To: Jason Anderssen janders...@exactal.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Getting involved Hi Jason, On Mon, Feb 18, 2013 at 2:45 PM, Jason Anderssen janders...@exactal.com wrote: With a background in development (both windows and MAC) I was wanting to get involved in an open source project that I believe is going to make the world a greater place. So I have decided to get involved with the WebKit project. I would like to start of by performing the boring work of reformatting code to suite the guidelines as stipulated on the webkit.org website (and double check that they are still up to date), and would like recommendations to which parts of the project could do with the re-formatting first up. ( I feel this will get me to know the framework, and structure of the code base well, before I can start inputting my coding and help. ) Any feedback to where to start would be very much appreciated. Also I have the code all built, however if I ./run-safari I get Can't find built framework at /Users/jason/research/webkit/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore. I will work out the problem, but in case someone knows exactly what I have done wrong, it may save me some time. First welcome to WebKit :) I am sure there is a better use of your time than fixing the coding style. A side project of mine is improving and cleaning some of WebKit testing infrastructure. There are some fairly easy tasks related to that if you are interested. I am sure others will have ideas of easy things to do to get started. For your build/run issues, it will be easier to ask on IRC #webkit than on the mailing list. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Getting involved
On Tue, Feb 19, 2013 at 11:29 AM, Dirk Pranke dpra...@chromium.org wrote: On http://trac.webkit.org/wiki there are a bunch of pages under Layout Tests and Performance Tests that describe much of the infrastructure. These days most of it is written in Python. I don't know what projects Benjamin has in mind so I don't know if that will match what he was referring to, but hopefully this will be helpful. Jason contacted me on IRC. To get started, I suggested to help moving the helper functions from DRT/WTR to Internals. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Proposal: Implement Stream and StreamReader
This API seems like it's in an inconsistent state with the other web platform features going on right now. ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for a constructor for Blob. It's a bit concerning that we're going to add this feature, and then perhaps change it, and then need to go through the how long does it take to deprecate features cycle again. What's the plan for turning this on? On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia z...@chromium.org wrote: Hi webkit-dev! I'm currently working on adding support for Stream and StreamReader to WebKit. https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This support will be behind the ENABLE_STREAM feature define. I have a prototype which implements readAsArrayBuffer() from an XHR connection at: https://bugs.webkit.org/show_bug.cgi?id=110194 Tests will be added as I change it to a real implementation. Cheers, -Zach ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Proposal: Implement Stream and StreamReader
Darin Fisher pointed out to me that this is about Stream and StreamReader per the subject, not StreamBuilder (which is not planned to be implemented yet). So sounds good to me! :) On Tue, Feb 19, 2013 at 1:28 PM, Elliott Sprehn espr...@chromium.orgwrote: This API seems like it's in an inconsistent state with the other web platform features going on right now. ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for a constructor for Blob. It's a bit concerning that we're going to add this feature, and then perhaps change it, and then need to go through the how long does it take to deprecate features cycle again. What's the plan for turning this on? On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia z...@chromium.org wrote: Hi webkit-dev! I'm currently working on adding support for Stream and StreamReader to WebKit. https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This support will be behind the ENABLE_STREAM feature define. I have a prototype which implements readAsArrayBuffer() from an XHR connection at: https://bugs.webkit.org/show_bug.cgi?id=110194 Tests will be added as I change it to a real implementation. Cheers, -Zach ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
On Wed, Feb 20, 2013 at 4:29 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto koivi...@iki.fi wrote: The problem with ComposedShadowTreeWalker is not that it is an iterator but that it is ill-defined and complex. It calls back to non-trivial, mutating functions on the structure being traversed (ContentDistributor::distribute!). Simply traversing a tree with it can apparently end up marking the tree for style recalc. This is a really good point. It encapsulates traversal of the composed tree, but this tree's integrity is maintained lazily, which means that as you traverse it, you could force the update. That ain't awesome. We could possibly separate the recalculation of the composed tree from style recalculation or attachment. Even though the valid tree is computed lazily, the invalidation happens eagerly, which triggers style recalculation. So we could let our style recalc lifecycle to handle it and make distribute() to focus on calculating distribution. This kind of clarification is apparently worth trying, an I believe current design is close to that shape. Filed http://wkb.ug/110280 for tracking. -- morrita :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
