Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 7, 2011, at 4:22 PM, Darin Adler wrote: I think the “make some things non-const” part of this would be the first part to put up for review and land. To expand on Darin's remark in two different ways: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear. 2) We like to do things incrementally and fixing bad use of const before adding good use of const seems like this is a logical way to split the work and make it less of a megapatch. (As a separate technical comment, I think it may be better to have the const versions call non-const versions (casting away const on this), because the non-const versions are likely to be called much more often so it's helpful to have fewer levels of indirection to wade through before seeing the real code, e.g. when inspecting code or debugging.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CSS_Regions/CSS_Exclusion slave build bot
Hi, In line with our efforts towards CSS_Regions/CSS_Exclusions support in WebKit, we intend to configure a slave build bot. We have a Mac Snow Leopard machine dedicated to this purpose. At this point, we need a username and a password to progress further. How can we obtain them? The build bot will use ENABLE(CSS_REGIONS)/ENABLE(CSS_EXCLUSIONS) and will build on Mac only. Regards, Mihnea ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling SVG lighting filters for ARM NEON
itisravi wrote: Hello all, Referring to https://lists.webkit.org/pipermail/webkit-help/2011-June/002150.html this , I'm trying to cross compile webkit 1.4 (gtk port) for ARM with NEON flags enabled for the SVG lighting filters.Though both -mfpu=neon and -mfloat-abi=softfp flags are enabled, the Source/WebCore/platform/graphics/filters/arm/FELightingNEON.cpp/h files are not getting compiled.The build fails with the following message: CCLD Programs/unittests/testapplicationcache ./.libs/libwebkitgtk-1.0.so: undefined reference to `WebCore::feLightingConstantsForNeon()' ./.libs/libwebkitgtk-1.0.so: undefined reference to `neonDrawLighting' I also noted that the toplevel GNUMakefile does not contain rules to build FELightingNEON files. I tried adding them in vain. Source/WebCore/platform/graphics/filters/FELighting.cpp \Already present Source/WebCore/platform/graphics/filters/FELighting.h \ Already present Source/WebCore/platform/graphics/filters/arm/FELightingNEON.cpp \ Added by me Source/WebCore/platform/graphics/filters/arm/FELightingNEON.h \ Added by me Any inputs are appreciated. Also, if I'm adding new source files to say the filters section, where exactly do I have to give the names of these files so that the webkit build system picks them up? Looking at the original https://bugs.webkit.org/attachment.cgi?id=88974action=diff patch , I suppose adding the names to Source/WebCore/WebCore.pri /pro should do it? Best regards, Ravi I managed to compile it by adding the FELightingNEON files to /Source/WebCore/GNUMakefile.list.am. Wondering why it was not mentioned in the original patch(Changeset 83835) -- View this message in context: http://old.nabble.com/Compiling-SVG-lighting-filters-for-ARM--NEON-tp31797915p31799947.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS_Regions/CSS_Exclusion slave build bot
On Jun 7, 2011, at 11:51 PM, Mihnea-Vlad Ovidenie wrote: Hi, In line with our efforts towards CSS_Regions/CSS_Exclusions support in WebKit, we intend to configure a slave build bot. We have a Mac Snow Leopard machine dedicated to this purpose. At this point, we need a username and a password to progress further. How can we obtain them? File a bug and attach a patch to add your slaves and any necessary steps/options. CC me and Adam Roben. You can name the slave yourself (try to follow the existing conventions). After the patch lands, you will be given a password to use with the name you chose. http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bot master supports new-run-webkit-tests now
Hi all, As of this morning, build.webkit.org master reports the number of failures, flaky tests, and new passes (aka unexpected passes) on test bots that run new-run-webkit-tests. I encourage you to take a look at Chromium Mac Release (Tests)http://build.webkit.org/waterfall?show=Chromium%20Mac%20Release%20(Tests) and Chromium Linux Release (Tests)http://build.webkit.org/waterfall?show=Chromium%20Linux%20Release%20(Tests) . (I also fixed a bug in test archiving script for chromium port so results.html is now archived uploaded correctly). Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org 's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Maybe, it would involve disabling CSS parser rules at runtime. I don't think we have any code that currently tries to do this. On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear. There are a surprising number of places that actually do const traversals. Simply making all these accessors non-const will require removing a lot of valid const usage from the existing code. I'm really uncomfortable with that. 2) We like to do things incrementally and fixing bad use of const before adding good use of const seems like this is a logical way to split the work and make it less of a megapatch. Incremental fixes are absolutely the way to go. Reviewing megapatches sucks and it's hard to catch subtle bugs like you changed this function to be not const, but there's no reason to do that. Perhaps a split that avoids removing existing, valid const usage would be to first change few (or no) function signatures, and simply modify caller code to be more consistent about type declarations. This would mean converting some callers from Node* to const Node* when they're doing true const traversals, and some the opposite direction when they're not. The goal would be to make eventual API changes a no-op in terms of caller effect. It'd be easy to make these sorts of patches arbitrarily small as well. (As a separate technical comment, I think it may be better to have the const versions call non-const versions (casting away const on this), because the non-const versions are likely to be called much more often so it's helpful to have fewer levels of indirection to wade through before seeing the real code, e.g. when inspecting code or debugging.) I totally agree that these sorts of indirections are suboptimal (especially for common cases). The particular idea you propose isn't safe because there's no protection against the non-const impl actually causing side effects. Even if current implementations don't, it's easy to add a subtle bug like this in the future. And while compilers won't enforce this perfectly, they'll do a better and better job (better than nothing, for sure) as we change more APIs to enforce logical constness. (I hate to keep referencing it, but the end of Effective C++ Item 3 directly addresses this implementation idea in more detail. That whole section is really worth reading for anyone deeply interested in this issue.) However, I think we should at least try to limit the number of accessor pairs to only those cases which really need them. What about this plan: * I'll post a patch that just addresses the caller-side constness issues I've found from my work so far. * Then in my local checkout I'll start trying to see which accessor pairs I can collapse back to one accessor, be it const or non-const. I'll post patches to make any necessary caller-side changes here, too. * Finally I'll post a patch to change method signatures and add accessor pairs where necessary. * Then rinse and repeat with another class, e.g. Element. I'll go ahead and file a bug and start posting real diffs to look at unless this plan has fatal flaws. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote: On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear. There are a surprising number of places that actually do const traversals. Simply making all these accessors non-const will require removing a lot of valid const usage from the existing code. I'm really uncomfortable with that. I thought you did it already locally. You mentioned that you decided for many member functions that the right thing was to remove const. I suggested you land those changes first, before making the other changes. Are we talking about the same thing? Maybe you think Maciej is asking for something he’s not. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler da...@apple.com wrote: On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote: On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear. There are a surprising number of places that actually do const traversals. Simply making all these accessors non-const will require removing a lot of valid const usage from the existing code. I'm really uncomfortable with that. I thought you did it already locally. You mentioned that you decided for many member functions that the right thing was to remove const. I suggested you land those changes first, before making the other changes. Are we talking about the same thing? Maybe you think Maciej is asking for something he’s not. Maybe I got confused. Some accessors cannot be const at all (IMO), like the ones that update layout before returning the desired value. Other accessors, e.g. parentNode(), don't themselves do anything non-const and so they could theoretically be valid as const and non-const versions. What I thought Maciej was saying was that we should remove const on all the existing accessors, in both categories, which sounded different than what you were saying (which I read as remove const on the accessors in the first category). I'm perfectly happy removing const from accessors in the first category. I can post a change that does that before going any further. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote: What I thought Maciej was saying was that we should remove const on all the existing accessors, in both categories, which sounded different than what you were saying (which I read as remove const on the accessors in the first category). I'm perfectly happy removing const from accessors in the first category. I can post a change that does that before going any further. Yes, I believe that’s what both Maciej and I were suggesting. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler da...@apple.com wrote: On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote: I'm perfectly happy removing const from accessors in the first category. I can post a change that does that before going any further. Yes, I believe that’s what both Maciej and I were suggesting. Great. I filed https://bugs.webkit.org/show_bug.cgi?id=62302 about this and will proceed there. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] commit-queue platform musical chairs
I noticed that the commit-queue is a lot zippier now. Thanks! Nico On Wed, Jun 8, 2011 at 1:57 PM, Adam Barth aba...@webkit.org wrote: Update: The new commit-queue nodes run about 6x faster than the old nodes (wow). We're now fully switched over and have re-allocated the Mac Minis to the mac-ews, which should give us enough capacity to run the tests on Mac for every patch that's up for review. Adam On Sat, Jun 4, 2011 at 2:33 AM, Adam Barth aba...@webkit.org wrote: Up until now, we've been running the commit-queue on a cluster of Mac Minis, but building WebKit on these machines takes on the order of an hour and a half, making the commit-queue slow. EC2 offers much stronger machines, but unfortunately does not offer Mac OS X (likely due to licensing restrictions). We're experimenting with running the commit-queue on EC2 using the Chromium Linux port. Currently, we've got both kinds of nodes running so we can compare their effectiveness. I have a slight worry that most developers use the Mac port, and running the commit-queue in a different configuration might cause some trouble. If something bad happens, please let me know. We might need to add some more checks to make sure the commit-queue doesn't break Mac. Thanks for your patience, Adam ___ 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
Re: [webkit-dev] Parallel CSS styling
Re-sending w/o the attached file. On Wed, Jun 8, 2011 at 3:31 PM, Eric Seidel e...@webkit.org wrote: I used Safari's built-in Page Load Test mechanism to test the page. I created a flickr.pltsuite and placed it in /Applications/Safari.app/Contents/Resources/flickr.pltsuite with the contents: http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco Using http urls (instead of local file urls) in PLT suites is not recommended, as network load causes the results to be wildly inconsistent, but does provide an easy way to get Safari to reload the same page multiple times (and allows for easy sharking of Safari). An average run of this PLT took between 7 and 9 seconds on my machine (loading this flickr page 5 times in a row): FINISHED: Total Time = 9178.8 ms Mean Time = 1835.8 ms Square-Mean-Root Time = 1816.4 ms Heap Size = 11.61 MB I Sharked safari while running my flickr plt, and found that styleForElement accounted for 0.4% of total time spent loading/reloading flickr.com/photos/tags/sanfrancisco. I've attached my shark sample (but doubt it will succeed in going through to the list). Feel free to email me if you want it. For giggles I also loaded up the Web Inspector in Chrome and used the Timeline view to record events. Looking at only the rendering events, we see a total of 7 resolve style events, totally 10ms in time. Now, it's very possible that our internal counters are missing some time spent in rendering, but I don't think they're missing anywhere near enough to mean that this actually affects page load time. Although I suspect you're optimizations are very interesting. I believe you're optimizing the wrong things here. Best of luck. -eric On Tue, Jun 7, 2011 at 11:54 AM, Eric Seidel e...@webkit.org wrote: You noted it spends 66% of its CSS time in StyleForElement. What about total page load time? Then again 6450ms spent in CSS sounds like a lot of time regardless. Answering what % of total page load time we're spending in CSS (or StyleForElement) is important. Loading www.flickr.com/photos/tags/sanfrancisco on my 4-core 2.66ghz Mac Pro doesn't take anywhere near 6 (or for that mater 9!) seconds, so I'm confused how you got 9s in CSS code on a (supposedly faster) machine loading that flickr page. I'm building WebCore so I can shark the page now. Thanks again for your investigation efforts. -eric On Tue, Jun 7, 2011 at 11:22 AM, Kulanthaivel Palanichamy kulanthai...@codeaurora.org wrote: Eric, You're right that in flickr.com main page, Webkit spends very little time in StyleForElement. However, if you visit http://www.flickr.com/photos/tags/sanfrancisco/ , WebKit spends most of its CSS time in StyleForElement. For example, in our test machine (an 8-core Intel Xeon, 2.8GHz) StyleForElement takes 6450ms out of 9748 ms spent on CSS (66%). Our algorithm focuses on that 66%, and makes it scale linearly. The version of Webkit that we tested includes this patch: Bug 49876 - Optimize matching of descendant selectors Other websites that would benefit: • amazon (68% in SFE) • Google search (57%) • Yahoo sports (56%) • Apple (58%) • Wikipedia article (65%) -Kulanthaivel Do you have statistics on how much total time rendering flickr.com is in CSS/Style code at all? I believe it to be very low. -eric On Mon, Jun 6, 2011 at 1:16 PM, Kulanthaivel Palanichamy kulanthai...@codeaurora.org wrote: Hi All, At Qualcomm Innovation Center we have been working on a parallel algorithm for CSS styling and wanted to see if there is any interest in the community to see it implemented in WebKit. The overall idea is that we replace CSS matching and styling with a parallel implementation assuming there is a barrier before and after the computation. CSS style application will be performed by the main thread, such that we avoid the need to make thread safe data structures accessed in other passes. The algorithm is task-based, so we would need to implement a thread pool and a simple task scheduler (or maybe use an existing one). In particular, our algorithm requires modifying Element::recalcStyle() and some of the methods it invokes. Code that calls Element::recalcStyle() will not have to be changed. By the time Element::recalStyle() returns, all threads involved on the parallel CSS styling have completed their execution. Effectively, there is a barrier when Element::recalcStyle() begins and another before it returns. Our experiments show that our CSS computation for complex websites scales rather well. For example, we observed that, for flickr.com, Webkit spends 75% of its time in CSS doing CSS matching. Thus, our algorithm would give a maximum speedup of 1.6X on 2
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
If you're super worried about folks shipping the feature before it's ready, then that approach can make sense. I'm not sure how well it scales, but we can worry about that problem when we have N such configurations. Adam On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote: I don't understand how changing the name prevents the feature from being shipped half-done. If we're going to ship a half-done feature, we may as well use the vendor prefixed name so sites don't depend on the goofy name. However, I'm willing to run a buildbot for this and that seems better than shipping a half-done feature. I don't expect it to be a core builder and Ojan and I will be the ones keeping it green. Isn't this what we're doing for other features like CSS Regions and Exclusions? On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote: It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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.cgi/webkit-dev
Re: [webkit-dev] Parallel CSS styling
If you are interested in optimization suggestions inside WebKit, I'm happy to have a lengthy discussion with you over #webkit. We've talked about moving the HTML5 parser off into its own thread, which may be a win on some pages. WebCore's memory usage is way too high (which also affects execution time). James Robinson, Simon Jameson and others at Google have looked at perf in the recent past. Maciej Stachowiak, Geoff Garen, Oliver Hunt and Gavin Barraclough are also perf experts @ Apple. We're all reachable in #webkit and happy to talk with you about perf in WebKit as we're very interested in making things faster! Again, best of luck with your efforts. At this time WebKit does not believe that parallel CSS styling would yield any noticeable performance increase on standard page loads. -eric On Wed, Jun 8, 2011 at 3:31 PM, Eric Seidel e...@webkit.org wrote: I used Safari's built-in Page Load Test mechanism to test the page. I created a flickr.pltsuite and placed it in /Applications/Safari.app/Contents/Resources/flickr.pltsuite with the contents: http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco http://www.flickr.com/photos/tags/sanfrancisco Using http urls (instead of local file urls) in PLT suites is not recommended, as network load causes the results to be wildly inconsistent, but does provide an easy way to get Safari to reload the same page multiple times (and allows for easy sharking of Safari). An average run of this PLT took between 7 and 9 seconds on my machine (loading this flickr page 5 times in a row): FINISHED: Total Time = 9178.8 ms Mean Time = 1835.8 ms Square-Mean-Root Time = 1816.4 ms Heap Size = 11.61 MB I Sharked safari while running my flickr plt, and found that styleForElement accounted for 0.4% of total time spent loading/reloading flickr.com/photos/tags/sanfrancisco. I've attached my shark sample (but doubt it will succeed in going through to the list). Feel free to email me if you want it. For giggles I also loaded up the Web Inspector in Chrome and used the Timeline view to record events. Looking at only the rendering events, we see a total of 7 resolve style events, totally 10ms in time. Now, it's very possible that our internal counters are missing some time spent in rendering, but I don't think they're missing anywhere near enough to mean that this actually affects page load time. Although I suspect you're optimizations are very interesting. I believe you're optimizing the wrong things here. Best of luck. -eric On Tue, Jun 7, 2011 at 11:54 AM, Eric Seidel e...@webkit.org wrote: You noted it spends 66% of its CSS time in StyleForElement. What about total page load time? Then again 6450ms spent in CSS sounds like a lot of time regardless. Answering what % of total page load time we're spending in CSS (or StyleForElement) is important. Loading www.flickr.com/photos/tags/sanfrancisco on my 4-core 2.66ghz Mac Pro doesn't take anywhere near 6 (or for that mater 9!) seconds, so I'm confused how you got 9s in CSS code on a (supposedly faster) machine loading that flickr page. I'm building WebCore so I can shark the page now. Thanks again for your investigation efforts. -eric On Tue, Jun 7, 2011 at 11:22 AM, Kulanthaivel Palanichamy kulanthai...@codeaurora.org wrote: Eric, You're right that in flickr.com main page, Webkit spends very little time in StyleForElement. However, if you visit http://www.flickr.com/photos/tags/sanfrancisco/ , WebKit spends most of its CSS time in StyleForElement. For example, in our test machine (an 8-core Intel Xeon, 2.8GHz) StyleForElement takes 6450ms out of 9748 ms spent on CSS (66%). Our algorithm focuses on that 66%, and makes it scale linearly. The version of Webkit that we tested includes this patch: Bug 49876 - Optimize matching of descendant selectors Other websites that would benefit: • amazon (68% in SFE) • Google search (57%) • Yahoo sports (56%) • Apple (58%) • Wikipedia article (65%) -Kulanthaivel Do you have statistics on how much total time rendering flickr.com is in CSS/Style code at all? I believe it to be very low. -eric On Mon, Jun 6, 2011 at 1:16 PM, Kulanthaivel Palanichamy kulanthai...@codeaurora.org wrote: Hi All, At Qualcomm Innovation Center we have been working on a parallel algorithm for CSS styling and wanted to see if there is any interest in the community to see it implemented in WebKit. The overall idea is that we replace CSS matching and styling with a parallel implementation assuming there is a barrier before and after the computation. CSS style application will be performed by the main thread, such that we avoid the need to make thread safe data structures accessed in other passes. The algorithm is task-based, so
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
It seems like it doesn't scale very well to have to stand-up new buildbots for each new feature. At least in the Chromium port, it is possible for the Chromium repo to override ENABLE_ flags so that only DRT gets built with a prototype feature, making it easy to test a prototype feature using existing buildbots. -Darin On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth aba...@webkit.org wrote: If you're super worried about folks shipping the feature before it's ready, then that approach can make sense. I'm not sure how well it scales, but we can worry about that problem when we have N such configurations. Adam On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote: I don't understand how changing the name prevents the feature from being shipped half-done. If we're going to ship a half-done feature, we may as well use the vendor prefixed name so sites don't depend on the goofy name. However, I'm willing to run a buildbot for this and that seems better than shipping a half-done feature. I don't expect it to be a core builder and Ojan and I will be the ones keeping it green. Isn't this what we're doing for other features like CSS Regions and Exclusions? On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote: It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org wrote: It seems like it doesn't scale very well to have to stand-up new buildbots for each new feature. At least in the Chromium port, it is possible for the Chromium repo to override ENABLE_ flags so that only DRT gets built with a prototype feature, making it easy to test a prototype feature using existing buildbots. If you mean by using feature_overrides.gypi to overwrite features.gypi, that mechanism doesn't actually work and people have attempted to remove it. The bots that we actually pay attention to all use feature_overrides.gypi. I would not encourage that pattern. - James -Darin On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth aba...@webkit.org wrote: If you're super worried about folks shipping the feature before it's ready, then that approach can make sense. I'm not sure how well it scales, but we can worry about that problem when we have N such configurations. Adam On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote: I don't understand how changing the name prevents the feature from being shipped half-done. If we're going to ship a half-done feature, we may as well use the vendor prefixed name so sites don't depend on the goofy name. However, I'm willing to run a buildbot for this and that seems better than shipping a half-done feature. I don't expect it to be a core builder and Ojan and I will be the ones keeping it green. Isn't this what we're doing for other features like CSS Regions and Exclusions? On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote: It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. - James -Darin On Wed, Jun 8, 2011 at 4:29 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org wrote: It seems like it doesn't scale very well to have to stand-up new buildbots for each new feature. At least in the Chromium port, it is possible for the Chromium repo to override ENABLE_ flags so that only DRT gets built with a prototype feature, making it easy to test a prototype feature using existing buildbots. If you mean by using feature_overrides.gypi to overwrite features.gypi, that mechanism doesn't actually work and people have attempted to remove it. The bots that we actually pay attention to all use feature_overrides.gypi. I would not encourage that pattern. - James -Darin On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth aba...@webkit.org wrote: If you're super worried about folks shipping the feature before it's ready, then that approach can make sense. I'm not sure how well it scales, but we can worry about that problem when we have N such configurations. Adam On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote: I don't understand how changing the name prevents the feature from being shipped half-done. If we're going to ship a half-done feature, we may as well use the vendor prefixed name so sites don't depend on the goofy name. However, I'm willing to run a buildbot for this and that seems better than shipping a half-done feature. I don't expect it to be a core builder and Ojan and I will be the ones keeping it green. Isn't this what we're doing for other features like CSS Regions and Exclusions? On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote: It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Anyways, all of this is just to avoid what would ultimately be a much better solution: it should be possible to develop runtime enabled CSS features. Then, we wouldn't worry about different build configs or having to stand-up different build bots. It would be easier for the next person wanting to develop a new CSS feature. -Darin - James -Darin On Wed, Jun 8, 2011 at 4:29 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org wrote: It seems like it doesn't scale very well to have to stand-up new buildbots for each new feature. At least in the Chromium port, it is possible for the Chromium repo to override ENABLE_ flags so that only DRT gets built with a prototype feature, making it easy to test a prototype feature using existing buildbots. If you mean by using feature_overrides.gypi to overwrite features.gypi, that mechanism doesn't actually work and people have attempted to remove it. The bots that we actually pay attention to all use feature_overrides.gypi. I would not encourage that pattern. - James -Darin On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth aba...@webkit.org wrote: If you're super worried about folks shipping the feature before it's ready, then that approach can make sense. I'm not sure how well it scales, but we can worry about that problem when we have N such configurations. Adam On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote: I don't understand how changing the name prevents the feature from being shipped half-done. If we're going to ship a half-done feature, we may as well use the vendor prefixed name so sites don't depend on the goofy name. However, I'm willing to run a buildbot for this and that seems better than shipping a half-done feature. I don't expect it to be a core builder and Ojan and I will be the ones keeping it green. Isn't this what we're doing for other features like CSS Regions and Exclusions? On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote: It seems like the simplest thing is to have an ENABLE macro that's turned on and to use the normal bots. If you're really worried about folks shipping the feature half-done by accident, you can use a goofy name like -webkit-goofybox (or whatever) and rename it to the final name when you're ready. Adam On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote: Kind of. We could make the functionality only work at runtime, but adding the properties to the CSS parser would be difficult to make runtime configurable. So, the CSS properties would parse correctly but do nothing. That's especially problematic for properties like display that would then get an invalid value. My current plan was still to test this incrementally. We'd include tests as we went, but skip the flexbox subdirectory. We would just run the tests locally during development. This has the downside that other changes might break the flexbox tests, but thats a pain I'm willing to live with. I'm fine doing this differently if people have strong opinions. Ojan On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
No, but I hadn't even thought of that ;) Mostly I was thinking of the pain of developers having to keep track of which configuration was which, testing in both configurations, etc. -- Dirk On Wed, Jun 8, 2011 at 5:24 PM, Darin Fisher da...@chromium.org wrote: Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
The difference between runtime and compile time enabling seems like a red herring. The issue is more which configurations to test where and to ship where, not how to do the configuring. Adam On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote: Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JS bindings: Adding EventTarget to the prototype chain
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)
2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)
3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)
So this shows that, yes, this is not free, but it is low-single
digits. Since adding and removing event listeners is a relatively
infrequent operation, I think this is OK. I want to emphasize that the
change I’m proposing has no impact on native event *dispatch*, which
is obviously a lot more performance-sensitive than adding and
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
OK, but it is very nice to ship what you test (i.e., avoid the need to create a separate build of WebCore for testing). Continuous integration is also nice (i.e., no branches). Marrying those constraints leads to runtime enabling features. This is precisely the recipe Chromium uses to great avail for features exposed through JS. Why wouldn't we want the same for CSS features? -Darin On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth aba...@webkit.org wrote: The difference between runtime and compile time enabling seems like a red herring. The issue is more which configurations to test where and to ship where, not how to do the configuring. Adam On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote: Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
+1 for runtime configuration. Keeping code runnable is nice, and hard if it's disabled on many developers' working copies. We don't need to use traditional flag-holder like Settings class and can use simple global-ish variables instead, because We don't need to configure it per-Page basis. I personally prefer compilation ENABLE flag only for possible optional features, and most of CSS functionalities aren't that case. (This claim might be controversial though.) -- morrita On Thu, Jun 9, 2011 at 1:29 PM, Darin Fisher da...@chromium.org wrote: OK, but it is very nice to ship what you test (i.e., avoid the need to create a separate build of WebCore for testing). Continuous integration is also nice (i.e., no branches). Marrying those constraints leads to runtime enabling features. This is precisely the recipe Chromium uses to great avail for features exposed through JS. Why wouldn't we want the same for CSS features? -Darin On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth aba...@webkit.org wrote: The difference between runtime and compile time enabling seems like a red herring. The issue is more which configurations to test where and to ship where, not how to do the configuring. Adam On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote: Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
