Re: [webkit-dev] The Care and Feeding of WebCore Modules
== Likely Future Modules == filesystem = DISCUSS BEFORE MODULARIZATION notifications = DISCUSS BEFORE MODULARIZATION pagevisibility = DISCUSS BEFORE MODULARIZATION protocolhandler = DISCUSS BEFORE MODULARIZATION websql = DISCUSS BEFORE MODULARIZATION webaudio = DISCUSS BEFORE MODULARIZATION ^^^ I'd like to modularize these two relatively soon. webaudio is basically done. We're just waiting for crogers to give us the thumbs up to move the files. As for websql, it seems very parallel to indexeddb and likely should be implemented using a similar approach. Yeah. I just wanted to mean that let's announce here before starting modularization. Now I understand the modularization can be controversial. Another thing I've heard is that some folk got confused because we've moved websockets/ directory without the announcement. On Thu, Mar 1, 2012 at 4:56 PM, Adam Barth aba...@webkit.org wrote: On Wed, Feb 29, 2012 at 11:49 PM, Kentaro Hara hara...@chromium.org wrote: Thank you very much for the organization. Your suggestion sounds great to me. Just for clarification, I would like to confirm what action we should take for each item from now: == Existing Modules == gamepad = KEEP geolocation = KEEP indexeddb (work in progress) = KEEP intents = KEEP mediastream = KEEP vibration = KEEP websockets = KEEP == Likely Future Modules == filesystem = DISCUSS BEFORE MODULARIZATION notifications = DISCUSS BEFORE MODULARIZATION pagevisibility = DISCUSS BEFORE MODULARIZATION protocolhandler = DISCUSS BEFORE MODULARIZATION websql = DISCUSS BEFORE MODULARIZATION webaudio = DISCUSS BEFORE MODULARIZATION ^^^ I'd like to modularize these two relatively soon. webaudio is basically done. We're just waiting for crogers to give us the thumbs up to move the files. As for websql, it seems very parallel to indexeddb and likely should be implemented using a similar approach. Adam == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion = KEEP deviceoritentation = KEEP html (seems to be agreement on reverting this) = REVERT speechinput (seems to be agreement on keeping this) = KEEP svg = REVERT webgl = REVERT workers = REVERT xml = REVERT == Possibly Planned Future Uses of Module Techniques for non-Modules == events = WONT MODULARIZE If you have any concern, let's discuss here. If no objection, I'll start the above work from tomorrow. On Thu, Mar 1, 2012 at 4:31 PM, Maciej Stachowiak m...@apple.com wrote: Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation html (seems to be agreement on reverting this) speechinput (seems to be agreement on keeping this) svg webgl workers xml == Possibly Planned Future Uses of Module Techniques for non-Modules == events -- Assuming this reflects up-to-date plans, I can put it in a wiki page, though I'm not sure I'll always be able to keep it up to date with changes of plans. I would suggest that, based on the discussion so far, html, svg, webgl, workers, and xml should be de-quasi-modularized at least for now. I would also suggest not applying Module techniques to DOM events, at least for now, unless I misunderstand the intent. devicemotion and deviceorientation seem to be using Supplement in a similar way and for a similar reason to speechinput, so I'd presume folks are ok with those. We may also want to consider whether websockets is truly a good candidate for the module treatment. It seems to me that at some point soon, if not already, it will be mature and accepted enough to be considered part of the core, though the code is relatively standalone. Regards, Maciej -- Kentaro Hara, Tokyo, Japan (http://haraken.info) -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] svn.webkit.org
Hi, It seems Qt bots and developers are banned from svn.webkit.org. :((( Could you remove 160.114.0.0/16 network from the ban list, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
Hi All, I have been observing svn.webkit.org trac.webkit.org are up down very frequently since morning now both of them are down :( Is this kind of known problem? Regs, Rahaman -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba Sent: Thursday, March 01, 2012 1:46 PM To: WebKit Development; William Siegrist; Lucas Forschler Subject: [webkit-dev] svn.webkit.org Hi, It seems Qt bots and developers are banned from svn.webkit.org. :((( Could you remove 160.114.0.0/16 network from the ban list, please? br, Ossy ___ 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] svn.webkit.org
Hi All, To avoid overloading svn.webkit.org again and again with zillion svn checkout after rm -rf-ed working copies on the bots, I stopped all of our clobbered buildbot. After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. - class Factory(factory.BuildFactory): def __init__(self, platform, configuration, architectures, buildOnly, features=None, **kwargs): factory.BuildFactory.__init__(self) self.addStep(ConfigureBuild, platform=platform, configuration=configuration, architecture= .join(architectures), buildOnly=buildOnly, features=features) self.addStep(CheckOutSource) self.addStep(KillOldProcesses) ... - To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? br, Ossy Osztrogonac Csaba írta: It seems Qt bots and developers are banned from svn.webkit.org. :((( Could you remove 160.114.0.0/16 network from the ban list, please? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi All, To avoid overloading svn.webkit.org again and again with zillion svn checkout after rm -rf-ed working copies on the bots, I stopped all of our clobbered buildbot. After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. You can get a relatively up to date working copy from http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2. And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. There are two different options that we're investigating to address this thundering herd problem that tends to kill SVN after buildbot downtime: 1) Teach build slaves to fetch and unpack http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than using svn checkout. 2) Add additional hardware and load-balance svn.webkit.org across several machines so that the spike in load is distributed. I have a rough version of the former working locally on a test master I set up. I should be able to get it cleaned up enough to be usable later this week. The latter is obviously a more involved solution but would also generally improve SVN performance. I expect that we'll continue to pursue that solution regardless. - class Factory(factory.BuildFactory): def __init__(self, platform, configuration, architectures, buildOnly, features=None, **kwargs): factory.BuildFactory.__init__(self) self.addStep(ConfigureBuild, platform=platform, configuration=configuration, architecture= .join(architectures), buildOnly=buildOnly, features=features) self.addStep(CheckOutSource) self.addStep(KillOldProcesses) ... - To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? Pulling from git instead of SVN is certainly worth considering, but I wouldn't be surprised if this simply shifted the performance issue from svn.webkit.org to git.webkit.org. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing the Speech JavaScript API
Hello WebKit, Currently, there is some limited support for speech recognition in WebKit, by means of the x-webkit-speech attribute to input elements. We would like to continue the development of this to allow web apps to better utilize the possibilities of speech recognition and text-to-speech synthesis. In December, Google put forward a proposal [0] for a scripting-only subset of the API that was defined in the Speech XG Incubator Group Final Report [1]. A W3C Community Group is being started to develop the specification [2]. Anyone interested in this is welcome to join once the group is available. In the meantime, the spec proposal is currently hosted at [3]. We would like to start implementing this behind a compile-time flag (ENABLE_SCRIPTED_SPEECH) and vendor prefix. A first patch is uploaded to the bug tracker [4]. Thanks, Hans [0]. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [1]. http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2]. http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0438.html [3]. http://speech-javascript-api-spec.googlecode.com/git/speechapi.html [4]. https://bugs.webkit.org/show_bug.cgi?id=80019 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
Mark Rowe írta: On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. You can get a relatively up to date working copy from http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2. We always have relatively up-to-date working copy. It is faster then downloading from you. ;) (I tried to download this nightly and the ETA is ~3 hours ...) Additionally we use svn 1.7 (to make our bots faster, and less IO intensive) which has different working copy than svn 1.6 . And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. There are two different options that we're investigating to address this thundering herd problem that tends to kill SVN after buildbot downtime: 1) Teach build slaves to fetch and unpack http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than using svn checkout. To do it, all slave must use same svn version. 2) Add additional hardware and load-balance svn.webkit.org across several machines so that the spike in load is distributed. It is a good idea. ;) To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? Pulling from git instead of SVN is certainly worth considering, but I wouldn't be surprised if this simply shifted the performance issue from svn.webkit.org to git.webkit.org. No, I don't want to shift the load from svn.webkit.org to git.webkit.org. But make all port maintainer to use their own git mirror for the bots instead of the root svn/git.webkit.org. Mirroring git.webkit.org locally is the simplest thing in the world. :) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
On 2012-03-01, at 04:28, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Mark Rowe írta: On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. You can get a relatively up to date working copy from http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2. We always have relatively up-to-date working copy. It is faster then downloading from you. ;) (I tried to download this nightly and the ETA is ~3 hours ...) Additionally we use svn 1.7 (to make our bots faster, and less IO intensive) which has different working copy than svn 1.6 . I'm surprised that it downloads so slowly for you. Do you have a rough idea how long a fresh svn checkout of WebKit trunk takes? I'd expect the tarball to download more quickly than svn can fetch. And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. There are two different options that we're investigating to address this thundering herd problem that tends to kill SVN after buildbot downtime: 1) Teach build slaves to fetch and unpack http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than using svn checkout. To do it, all slave must use same svn version. They'd need to use the same version or newer. It's trivial to have the slave upgrade the working copy if necessary after unpacking it. 2) Add additional hardware and load-balance svn.webkit.org across several machines so that the spike in load is distributed. It is a good idea. ;) To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? Pulling from git instead of SVN is certainly worth considering, but I wouldn't be surprised if this simply shifted the performance issue from svn.webkit.org to git.webkit.org. No, I don't want to shift the load from svn.webkit.org to git.webkit.org. But make all port maintainer to use their own git mirror for the bots instead of the root svn/git.webkit.org. Mirroring git.webkit.org locally is the simplest thing in the world. :) I'd prefer to avoid forcing people to set up their own mirrors if at all possible. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Here are some things that may help; *#1 svn server overloading when all the slaves bootstrap at the same time* The only good work around is to keep an internal read-only svn-mirror that the slaves use instead of the real svn server. This means that builds must be triggered on the svn-mirror, which may incurs a delay of a few seconds, due to svnsync polling. My hypothesis is that svn has repo-wide locks while committing, so when there are a lot of readers, they are all starved whenever some action is happening. Doing the svn-mirror trick helped us to scale in the range past *several hundreds of simultaneous active connections*. As a guidance, gclient sync does 8 svn connections per slave by default. Scale that to hundreds of slaves waking up at the same time... Also, serving the read-only svn server from a set of apache frontends helps. We do that with src.chromium.org. To be clear, above I was talking about a DMZ-only mirror. It is a different one from the apache frontends. Implementing both has the biggest benefit. *#2 Using Chromium's git svn clone of webkit* We have a few read only git frontends that are relatively speedy. I just verified and both master@HEAD matches: git remote add chromium http://git.chromium.org/external/Webkit.git git fetch chromium Once you verified that the hash matches locally with: git fetch --all git log -1 origin/master git log -1 chromium/master Then you may want to; git config remote.chromium.fetch +refs/heads/*:refs/remotes/origin/* git branch -r -D chromium/master I give no guarantee what-so-ever about freshness, lack of corruption, consistent performance, availability, YMMV, etc. Note the url has a lower K! Note that we also have WebKit_trimmed.git (note the upper case K!) that is much smaller due to removal of many files chromium developers don't need but it has invalid hashes so *do not fetch this one in your current webkit git-svn clone*. *#3 Buildbot's (absence of) performance* Stefan (cc'ed) is also looking at this and has been profiling our slowest masters for a while. In our case, we are CPU-bound and it looks like we have to tune our caching. Stefan can explain it better than me. You guys probably want to talk together. Hope this is useful, M-A Le 29 février 2012 21:50, William Siegrist wsiegr...@apple.com a écrit : We're back to the slaves overloading svn. The Apple slaves are blocked temporarily while everyone else catches up. Sorry for the inconvenience. -Bill ___ 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] git.webkit.org problem
Hi, Marc-Antoine Ruel írta: Here are some things that may help; *#1 svn server overloading when all the slaves bootstrap at the same time* The only good work around is to keep an internal read-only svn-mirror that the slaves use instead of the real svn server. This means that builds must be triggered on the svn-mirror, which may incurs a delay of a few seconds, due to svnsync polling. My hypothesis is that svn has repo-wide locks while committing, so when there are a lot of readers, they are all starved whenever some action is happening. Doing the svn-mirror trick helped us to scale in the range past /several hundreds of simultaneous active connections/. As a guidance, gclient sync does 8 svn connections per slave by default. Scale that to hundreds of slaves waking up at the same time... Also, serving the read-only svn server from a set of apache frontends helps. We do that with src.chromium.org http://src.chromium.org. To be clear, above I was talking about a DMZ-only mirror. It is a different one from the apache frontends. Implementing both has the biggest benefit. We like the idea to setup svn mirrors, and we are ready to setup an svn mirror for Qt buildslaves hosted in Szeged. (6 slaves connected to build.webkit.org master and 13 slaves connected to build.webkit.sed.hu master) I think this mirror would help to reduce the load of svn.webkit.org and avoid rm -rf because of slow and not so stable trans-atlantic network connection. If there isn't any objection against adding an svn.webkit.sed.hu mirror, we will start to setup the server and prepare the master.cfg change to make slaves to be able to use svn mirrors, and add new scheduler to trigger slaves depends on their svn mirror used. And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Mar 1, 2012, at 7:56 AM, Osztrogonac Csaba wrote: And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? How would you want svn.webkit.org to signal the mirror? I think having svn.webkit.org request a specific HTTP URL would work. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] -webkit-transform-origin-x,y CSS properties
On Feb 29, 2012, at 9:44 AM, Simon Fraser wrote:
On Feb 29, 2012, at 9:32 AM, Hans Muller wrote:
Are the -webkit-transform-origin-x,y CSS properties on their way in our
out? The ugly little test below demonstrates that they're probably not
supported by Opera or Mozilla.
They are not in the spec:
http://www.w3.org/TR/css3-transforms/
We will not be supporting the unprefixed versions of these properties.
The question was more, if we will continue supporting the prefixed version of
these properties. Even if you did not answer directly, your answer implies that
you want to continue to support them.
Dirk
Simon
CSSComputedStyleDeclaration::getPropertyCSSValue() in WebKit (explicitly)
ignores them. Should they stay or should they go? Or perhaps they
should just be left alone?
Thanks,
- Hans
html
style
div.square {
position: absolute;
top: 150px;
left: 150px;
width: 100px;
height: 100px;
background-color: blue;
-webkit-transform-origin-x: -150px;
-webkit-transform-origin-y: -150px;
-webkit-transition: -webkit-transform 0.5s;
-moz-transform-origin-x: -150px;
-moz-transform-origin-y: -150px;
-moz-transition: -moz-transform 0.5s;
-o-transform-origin-x: -150px;
-o-transform-origin-y: -150px;
-o-transition: -o-transform 0.5s;
}
div.square:hover {
-webkit-transform: rotate(45deg);
-webki-transition: -webkit-transform 0.5s;
-moz-transform: rotate(45deg);
-moz-transition: -moz-transform 0.5s;
-o-transform: rotate(45deg);
-o-transition: -o-transform 0.5s;
}
/style
body
div class=square/div
/body
/html
___
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] git.webkit.org problem
Hi, William Siegrist írta: On Mar 1, 2012, at 7:56 AM, Osztrogonac Csaba wrote: And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? How would you want svn.webkit.org to signal the mirror? I think having svn.webkit.org request a specific HTTP URL would work. My first idea was that I gives you ssh or something else access to the svn mirror and the following post-commit hook will do the synchronization: /usr/local/bin/svnsync synchronize --username svnsync svn+ssh://svnsync@remote/home/svnsync/svn But your suggestion is reasonable and more safe than mine, when svn.webkit.org does a specific HTTP request and then our svn mirror will start the synchronization. Let's talk about it in private mail after we finished setting up the server. PS. So could you unban our subnet in the near future, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Introducing run-perf-tests and Adding Performance Bots
A Qt WebKit1 performance bot was added last week, sorry for the late announcement. If I'm not mistaken, currently run-perf-tests works with DRT only, but what if we would like to make it work with WTR as well so we could also have WebKit2 performance bots running? I'm not aware of the infrastructure provided by webkitpy (Drivers, etc) so I'm not sure about the amount of work needed... Cheers, jesus On Tue, Jan 31, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: FYI, I've added a wiki page describing how to write a new perf. test: https://trac.webkit.org/wiki/Writing%20Performance%20Tests On Fri, Jan 20, 2012 at 11:20 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 19, 2012 at 3:20 PM, Ryosuke Niwa rn...@webkit.org wrote: I didn't merge it into run-webkit-tests because performance tests don't pass/fail but instead give us some values that fluctuate over time. While Chromium takes an approach to hard-code the rage of acceptable values, such an approach has a high maintenance cost and prone to problems such as having to increase the range periodically as the score slowly degrades over time. Also, as you can see on Chromium perf bots, the test results tend to fluctuate a lot so hard-coding a tight range of acceptable value is tricky. While this isn't perfect, I still think it's worth doing. I'm afraid that the maintenance cost here will be too high. Values will necessarily depend on each bot so we'll need number of tests×number of bots expectations, and I don't think people are enthusiastic about maintaining values like that over time (even I don't want to do that myself). Turning the bot red when a performance test fails badly is helpful for finding and reverting regressions quickly, which in turn helps identify smaller regressions more easily (large regressions mask smaller ones). I agree. Maybe we can obtain the historical average and standard deviation and turn bots red if the value doesn't fall within some value between 1 and 2 standard deviations. In either case, we have to get the bots running the tests and work on getting reliable data first. After http://trac.webkit.org/changeset/106211, values for most tests have gotten very stable. They tend to vary within 5% range. - Ryosuke ___ 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] spinoff from webkit-patch -g discussion
On Feb 29, 2012, at 3:28 PM, Dirk Pranke wrote: In my view, I would actually rather upload the combination of committed + staged + unstaged changes rather than be told I have to commit things; in other words, I actually prefer to commit what I've uploaded rather than upload what I've committed. Ah! This explains why I use webkit-patch differently. With many local branches, leaving staged/unstaged changes in the source tree would make it impossible to switch branches easily. I also don't think of bugs.webkit.org as an ancillary source code repository (if I delete my local changes), but maybe that's because I'm uploading fewer patches to bugs.webkit.org. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Introducing run-perf-tests and Adding Performance Bots
On Thu, Mar 1, 2012 at 6:41 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: A Qt WebKit1 performance bot was added last week, sorry for the late announcement. If I'm not mistaken, currently run-perf-tests works with DRT only, but what if we would like to make it work with WTR as well so we could also have WebKit2 performance bots running? I'm not aware of the infrastructure provided by webkitpy (Drivers, etc) so I'm not sure about the amount of work needed... To get WKTR running the performance tests a '-2' switch must be added to PerfTestRunner and some refactoring is required in the WKTR itself to properly handle the '--no-timeout' switch when given. I've got a diff of these changes laying around I can transform into a patch if there isn't one yet, just point me to a bug (or let's create one). Best, Zan Cheers, jesus On Tue, Jan 31, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: FYI, I've added a wiki page describing how to write a new perf. test: https://trac.webkit.org/wiki/Writing%20Performance%20Tests On Fri, Jan 20, 2012 at 11:20 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 19, 2012 at 3:20 PM, Ryosuke Niwa rn...@webkit.org wrote: I didn't merge it into run-webkit-tests because performance tests don't pass/fail but instead give us some values that fluctuate over time. While Chromium takes an approach to hard-code the rage of acceptable values, such an approach has a high maintenance cost and prone to problems such as having to increase the range periodically as the score slowly degrades over time. Also, as you can see on Chromium perf bots, the test results tend to fluctuate a lot so hard-coding a tight range of acceptable value is tricky. While this isn't perfect, I still think it's worth doing. I'm afraid that the maintenance cost here will be too high. Values will necessarily depend on each bot so we'll need number of tests×number of bots expectations, and I don't think people are enthusiastic about maintaining values like that over time (even I don't want to do that myself). Turning the bot red when a performance test fails badly is helpful for finding and reverting regressions quickly, which in turn helps identify smaller regressions more easily (large regressions mask smaller ones). I agree. Maybe we can obtain the historical average and standard deviation and turn bots red if the value doesn't fall within some value between 1 and 2 standard deviations. In either case, we have to get the bots running the tests and work on getting reliable data first. After http://trac.webkit.org/changeset/106211, values for most tests have gotten very stable. They tend to vary within 5% range. - Ryosuke ___ 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] Implementing the Speech JavaScript API
Hi Hans, On Thu, Mar 1, 2012 at 4:17 AM, Hans Wennborg h...@chromium.org wrote: Currently, there is some limited support for speech recognition in WebKit, by means of the x-webkit-speech attribute to input elements. We would like to continue the development of this to allow web apps to better utilize the possibilities of speech recognition and text-to-speech synthesis. In December, Google put forward a proposal [0] for a scripting-only subset of the API that was defined in the Speech XG Incubator Group Final Report [1]. I haven't read the whole report in detail (it's long!), but I noticed a few things on a brief read-through: 1) The report introduces two new elements, the reco and the tts elements. It's often the case that folks designing features believe that they need to introduce new HTML elements. The report says, The reco represents a speech input in a user interface, which makes me wonder why we don't just use input type=speech. 2) Similarly, it's unclear to me why we'd need a new tts element rather than just a new media type for the audio element. 3) I didn't understand the role the builtin URI scheme plays. What happens if, for example, I use builtin URIs in other places that URIs are allowed, such as img src=... or a href=... ? Adding a new URI scheme is even more expensive than adding new HTML element and should be done with care. In any case, this mailing list isn't really the right place to debate these details. That's something better done in the standards arena. A W3C Community Group is being started to develop the specification [2]. Anyone interested in this is welcome to join once the group is available. In the meantime, the spec proposal is currently hosted at [3]. This proposal looks much better. The document says it supports the majority of use-cases and sample code in the Incubator Group Final Report. It's unclear from your email which of these proposals you're interested in implementing. If you're planning to implement [3], that sounds like a good plan. If you're planning to implementing [1], you might want to get some more feedback from the broader community, including the HTML working group. We would like to start implementing this behind a compile-time flag (ENABLE_SCRIPTED_SPEECH) and vendor prefix. A first patch is uploaded to the bug tracker [4]. Please consider implementing this feature as a module: https://trac.webkit.org/wiki/Modules. Everything in [3] should be implementable in a module and will minimize the cost of this feature on the larger project. Thanks, Adam [0]. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [1]. http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2]. http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0438.html [3]. http://speech-javascript-api-spec.googlecode.com/git/speechapi.html [4]. https://bugs.webkit.org/show_bug.cgi?id=80019 ___ 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] -webkit-transform-origin-x,y CSS properties
On Mar 1, 2012, at 8:45 AM, Dirk Schulze wrote: On Feb 29, 2012, at 9:44 AM, Simon Fraser wrote: On Feb 29, 2012, at 9:32 AM, Hans Muller wrote: Are the -webkit-transform-origin-x,y CSS properties on their way in our out? The ugly little test below demonstrates that they're probably not supported by Opera or Mozilla. They are not in the spec: http://www.w3.org/TR/css3-transforms/ We will not be supporting the unprefixed versions of these properties. The question was more, if we will continue supporting the prefixed version of these properties. Even if you did not answer directly, your answer implies that you want to continue to support them. Yes, I think we need to continue to support them. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] spinoff from webkit-patch -g discussion
On Thu, Mar 1, 2012 at 9:43 AM, David Kilzer ddkil...@webkit.org wrote: On Feb 29, 2012, at 3:28 PM, Dirk Pranke wrote: In my view, I would actually rather upload the combination of committed + staged + unstaged changes rather than be told I have to commit things; in other words, I actually prefer to commit what I've uploaded rather than upload what I've committed. Ah! This explains why I use webkit-patch differently. With many local branches, leaving staged/unstaged changes in the source tree would make it impossible to switch branches easily. I also don't think of bugs.webkit.org as an ancillary source code repository (if I delete my local changes), but maybe that's because I'm uploading fewer patches to bugs.webkit.org. I'm only talking about handling ChangeLogs (and the final step of uploading a patch); generally speaking, I keep stuff committed locally, and I switch branches all the time. Because I am often working on either a largish change that'll need to be broken up for review, or several changes in parallel, I tend to defer generating the ChangeLog to the very last thing I do before uploading (so that the list of changes is correct and so the risk of merge conflicts is smaller). In that case having to do a prepare, then a commit, then an upload, is slightly more annoying that just upload and commit (especially since the diff in the upload often shows me some minor changes I need clean up). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org is very sick
It appears that build.webkit.org/console has been stale since http://trac.webkit.org/changeset/109329 Could someone look into that? - Ryosuke On Wed, Feb 29, 2012 at 9:15 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: FYI, The build server seems to be acting up again. All build servers are either stuck starting or stopping queues with a long backlog building up. http://build.webkit.org/one_line_per_build is taking forever (upwards of a dozen seconds) to load. -Ash -- *From:* William Siegrist wsiegr...@apple.com *To:* Osztrogonac Csaba o...@inf.u-szeged.hu *Cc:* webkit-dev@lists.webkit.org *Sent:* Friday, February 24, 2012 6:55 PM *Subject:* Re: [webkit-dev] build.webkit.org is very sick I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ 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] git.webkit.org problem
On Mar 1, 2012, at 9:36 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, William Siegrist írta: On Mar 1, 2012, at 7:56 AM, Osztrogonac Csaba wrote: And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? How would you want svn.webkit.org to signal the mirror? I think having svn.webkit.org request a specific HTTP URL would work. My first idea was that I gives you ssh or something else access to the svn mirror and the following post-commit hook will do the synchronization: /usr/local/bin/svnsync synchronize --username svnsync svn+ssh://svnsync@remote/home/svnsync/svn But your suggestion is reasonable and more safe than mine, when svn.webkit.org does a specific HTTP request and then our svn mirror will start the synchronization. Let's talk about it in private mail after we finished setting up the server. PS. So could you unban our subnet in the near future, please? We're going to try slowly bring on more slaves soon. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Mar 1, 2012, at 11:13 AM, William Siegrist wsiegr...@apple.com wrote: On Mar 1, 2012, at 9:36 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, William Siegrist írta: On Mar 1, 2012, at 7:56 AM, Osztrogonac Csaba wrote: And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? How would you want svn.webkit.org to signal the mirror? I think having svn.webkit.org request a specific HTTP URL would work. My first idea was that I gives you ssh or something else access to the svn mirror and the following post-commit hook will do the synchronization: /usr/local/bin/svnsync synchronize --username svnsync svn+ssh://svnsync@remote/home/svnsync/svn But your suggestion is reasonable and more safe than mine, when svn.webkit.org does a specific HTTP request and then our svn mirror will start the synchronization. Let's talk about it in private mail after we finished setting up the server. PS. So could you unban our subnet in the near future, please? We're going to try slowly bring on more slaves soon. The Szeged slaves are unblocked. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS properties vs. their JS bindings on the style object
How about making this a compile time flag or runtime flag so that Apple Dashboard and iOS can keep it but let other users of WebKit disable it? erik On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain benja...@webkit.org wrote: On Tue, Feb 28, 2012 at 9:48 PM, t...@codeaurora.org wrote: Seriously, I'm not sure how to proceed on this. It does seem to be outside the spec. Either update the spec or create a path to deprecate the bug. Personally, this feature sounds like it could be useful for web developers so updating the spec might not be a bad idea. Benjamin ___ 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] CSS properties vs. their JS bindings on the style object
We shouldn't fragment WebKit engine behavior like that, especially when the feature is already being used to detect WebKit browsers (any WebKit-based browser would just be shooting itself in the foot by removing support for this). My vote would be to just spec it. If Trident and WebKit already do it, let's just spec it and then FF and Opera can implement it too. dave (hy...@apple.com) On Mar 1, 2012, at 2:07 PM, Erik Arvidsson wrote: How about making this a compile time flag or runtime flag so that Apple Dashboard and iOS can keep it but let other users of WebKit disable it? erik On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain benja...@webkit.org wrote: On Tue, Feb 28, 2012 at 9:48 PM, t...@codeaurora.org wrote: Seriously, I'm not sure how to proceed on this. It does seem to be outside the spec. Either update the spec or create a path to deprecate the bug. Personally, this feature sounds like it could be useful for web developers so updating the spec might not be a bad idea. Benjamin ___ 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] Introducing run-perf-tests and Adding Performance Bots
I have opened the On Thu, Mar 1, 2012 at 3:17 PM, Žan Doberšek zandober...@gmail.com wrote: To get WKTR running the performance tests a '-2' switch must be added to PerfTestRunner and some refactoring is required in the WKTR itself to properly handle the '--no-timeout' switch when given. I've got a diff of these changes laying around I can transform into a patch if there isn't one yet, just point me to a bug (or let's create one). I have opened bug https://bugs.webkit.org/show_bug.cgi?id=80042 . Can you assign it to yourself? Best regards, jesus Best, Zan Cheers, jesus On Tue, Jan 31, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: FYI, I've added a wiki page describing how to write a new perf. test: https://trac.webkit.org/wiki/Writing%20Performance%20Tests On Fri, Jan 20, 2012 at 11:20 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 19, 2012 at 3:20 PM, Ryosuke Niwa rn...@webkit.org wrote: I didn't merge it into run-webkit-tests because performance tests don't pass/fail but instead give us some values that fluctuate over time. While Chromium takes an approach to hard-code the rage of acceptable values, such an approach has a high maintenance cost and prone to problems such as having to increase the range periodically as the score slowly degrades over time. Also, as you can see on Chromium perf bots, the test results tend to fluctuate a lot so hard-coding a tight range of acceptable value is tricky. While this isn't perfect, I still think it's worth doing. I'm afraid that the maintenance cost here will be too high. Values will necessarily depend on each bot so we'll need number of tests×number of bots expectations, and I don't think people are enthusiastic about maintaining values like that over time (even I don't want to do that myself). Turning the bot red when a performance test fails badly is helpful for finding and reverting regressions quickly, which in turn helps identify smaller regressions more easily (large regressions mask smaller ones). I agree. Maybe we can obtain the historical average and standard deviation and turn bots red if the value doesn't fall within some value between 1 and 2 standard deviations. In either case, we have to get the bots running the tests and work on getting reliable data first. After http://trac.webkit.org/changeset/106211, values for most tests have gotten very stable. They tend to vary within 5% range. - Ryosuke ___ 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] Implementing the Speech JavaScript API
Hi Adam, Hi Adam, The proposal is to implement [3] which is a pure JS API and no new html markup. It will be implemented as a module as you suggested. The first patch in [4] shows the first iteration of the implementation ( https://bugs.webkit.org/attachment.cgi?id=129679action=review ), though it will be broken into smaller patches and landed over the coming weeks. -- Cheers Satish On Thu, Mar 1, 2012 at 6:18 PM, Adam Barth aba...@webkit.org wrote: Hi Hans, On Thu, Mar 1, 2012 at 4:17 AM, Hans Wennborg h...@chromium.org wrote: Currently, there is some limited support for speech recognition in WebKit, by means of the x-webkit-speech attribute to input elements. We would like to continue the development of this to allow web apps to better utilize the possibilities of speech recognition and text-to-speech synthesis. In December, Google put forward a proposal [0] for a scripting-only subset of the API that was defined in the Speech XG Incubator Group Final Report [1]. I haven't read the whole report in detail (it's long!), but I noticed a few things on a brief read-through: 1) The report introduces two new elements, the reco and the tts elements. It's often the case that folks designing features believe that they need to introduce new HTML elements. The report says, The reco represents a speech input in a user interface, which makes me wonder why we don't just use input type=speech. 2) Similarly, it's unclear to me why we'd need a new tts element rather than just a new media type for the audio element. 3) I didn't understand the role the builtin URI scheme plays. What happens if, for example, I use builtin URIs in other places that URIs are allowed, such as img src=... or a href=... ? Adding a new URI scheme is even more expensive than adding new HTML element and should be done with care. In any case, this mailing list isn't really the right place to debate these details. That's something better done in the standards arena. A W3C Community Group is being started to develop the specification [2]. Anyone interested in this is welcome to join once the group is available. In the meantime, the spec proposal is currently hosted at [3]. This proposal looks much better. The document says it supports the majority of use-cases and sample code in the Incubator Group Final Report. It's unclear from your email which of these proposals you're interested in implementing. If you're planning to implement [3], that sounds like a good plan. If you're planning to implementing [1], you might want to get some more feedback from the broader community, including the HTML working group. We would like to start implementing this behind a compile-time flag (ENABLE_SCRIPTED_SPEECH) and vendor prefix. A first patch is uploaded to the bug tracker [4]. Please consider implementing this feature as a module: https://trac.webkit.org/wiki/Modules. Everything in [3] should be implementable in a module and will minimize the cost of this feature on the larger project. Thanks, Adam [0]. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [1]. http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2]. http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0438.html [3]. http://speech-javascript-api-spec.googlecode.com/git/speechapi.html [4]. https://bugs.webkit.org/show_bug.cgi?id=80019 ___ 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] git.webkit.org problem
William Siegrist írta: The Szeged slaves are unblocked. -Bill Many thanks, I copied up-to-date svn working copy to them and then started. I have only one more little request. Could you kick git.webkit.org too? It seems it is still stay on r109303. Our EWS would be happy if it works again. PS. Tomorrow we are going to setup the Szeged svn mirror. ;) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Mar 1, 2012, at 12:54 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: William Siegrist írta: The Szeged slaves are unblocked. -Bill Many thanks, I copied up-to-date svn working copy to them and then started. I have only one more little request. Could you kick git.webkit.org too? It seems it is still stay on r109303. Our EWS would be happy if it works again. Thanks for the reminder. It was next on my list to clean up. It should be caught up in a few minutes. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the Speech JavaScript API
On Thu, Mar 1, 2012 at 20:49, Satish Sampath sat...@chromium.org wrote: Hi Adam, The proposal is to implement [3] which is a pure JS API and no new html markup. Yes, what Satish said. My apologies for being a bit unclear about which one we plan implement. I have been following the ongoing refactoring work, and have been emailing with Morrita. It will be a Module, it will use the supplement pattern, etc. Thanks, Hans ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS properties vs. their JS bindings on the style object
I agree with Hyatt. It's not like this behavior is especially harmful or confusing. Authors are unlikely to run into properties with hyphens in the names unless they go looking. And it can be useful if you ever want to pass around actual CSS property names by string in an API - no need to convert them to the funky camel-case format before looking it up. So it seems more reasonable to just spec it, and it's certainly not a big enough deal to fork behavior between ports. Cheers, Maciej On Mar 1, 2012, at 12:31 PM, David Hyatt wrote: We shouldn't fragment WebKit engine behavior like that, especially when the feature is already being used to detect WebKit browsers (any WebKit-based browser would just be shooting itself in the foot by removing support for this). My vote would be to just spec it. If Trident and WebKit already do it, let's just spec it and then FF and Opera can implement it too. dave (hy...@apple.com) On Mar 1, 2012, at 2:07 PM, Erik Arvidsson wrote: How about making this a compile time flag or runtime flag so that Apple Dashboard and iOS can keep it but let other users of WebKit disable it? erik On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain benja...@webkit.org wrote: On Tue, Feb 28, 2012 at 9:48 PM, t...@codeaurora.org wrote: Seriously, I'm not sure how to proceed on this. It does seem to be outside the spec. Either update the spec or create a path to deprecate the bug. Personally, this feature sounds like it could be useful for web developers so updating the spec might not be a bad idea. Benjamin ___ 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] Adding -webkit-image-set CSS function
Hi all! Ted O'Connor recently proposed a new CSS function for the Images module to the CSS working group called image-set. The idea behind the feature is to allow authors to provide multiple variants of the same image at differing resolutions, and to allow the User Agent to choose the resource that is most appropriate at the time. We think this will be a great way to allow authors to specify high resolution resources for iPhone's retina display, and we imagine User Agents being able to choose different resolution resources when content is scaled or zoomed. There is some consensus on the list that a feature like this would be a good addition to CSS Images Level 4. Discussion is still ongoing about the exact syntax of the property, but we'd like to add an experimental implementation to WebKit; after all, such implementations often help guide features like this along. -Beth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] scoping Node destruction during DOM modifications
We have a lot of code (e.g. in ContainerNode.cpp or any of the editing code) that needs to RefPtr nodes to make sure they're not destroyed due to synchronous events like blur, mutation events, etc. For example, ContainerNode::removeChild needs to RefPtr the parent to make it's not destroyed during a sync event. Currently, we need to write careful code that knows whether any methods it's calling can fire sync events and RefPtrs all the appropriate nodes. I have a proposal to automate this in https://bugs.webkit.org/show_bug.cgi?id=80041. It certainly makes the code cleaner and safer, but it comes at a performance cost in some cases. Basically, any scope that needs to be careful of sync events adds a DOMRemovalScope at the top which keeps nodes from getting destroyed until the scope is destroyed (DOMRemovalScope adds them to a VectorRefPtrNode). In cases where we don't delete nodes, there's no performance impact. In cases where we delete nodes, this is always slower. I uploaded two performance tests to that bug: 1. Set innerHTML = on a node that has half a million children. This test goes from ~166ms to ~172ms on my machine. A 3.6% regression. 2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression. So destroying Nodes during synchronous events fired during a DOM mutation is significantly slower. This case is rare though. I had to think hard to come up with a case where we would hit this. For the most part, nodes don't actually get destroyed due to JS until a garbage collection occurs, which is usually after the event has completed and the DOMRemovalScope has been destroyed. The advantage of this is that it gives a simple way to address a common class of crash and potentially security bugs. The disadvantage of course is the possible performance hit. What do you think? Is this worth trying? Are there better ideas? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding -webkit-image-set CSS function
(Resending from the right address...) Hi Beth, Thanks for letting us know about this! The feature sounds gerat for anyone trying to make their pages more responsive. Are you going to add any compilation flags? Also, if there is a Bugzilla entry to track this, I'd like to know that. When announcing new feature, it would be appreciated if you mention these two points: http://trac.webkit.org/wiki/AddingFeatures Thanks, -- morrita On Fri, Mar 2, 2012 at 9:56 AM, Hajime Morrita morr...@google.com wrote: Hi Beth, Thanks for letting us know about this! The feature sounds gerat for anyone trying to make their pages more responsive. Are you going to add any compilation flags? Also, if there is a Bugzilla entry to track this, I'd like to know that. When announcing new feature, it would be appreciated if you mention these two points: http://trac.webkit.org/wiki/AddingFeatures Thanks, -- morrita On Fri, Mar 2, 2012 at 8:06 AM, Beth Dakin bda...@apple.com wrote: Hi all! Ted O'Connor recently proposed a new CSS function for the Images module to the CSS working group called image-set. The idea behind the feature is to allow authors to provide multiple variants of the same image at differing resolutions, and to allow the User Agent to choose the resource that is most appropriate at the time. We think this will be a great way to allow authors to specify high resolution resources for iPhone's retina display, and we imagine User Agents being able to choose different resolution resources when content is scaled or zoomed. There is some consensus on the list that a feature like this would be a good addition to CSS Images Level 4. Discussion is still ongoing about the exact syntax of the property, but we'd like to add an experimental implementation to WebKit; after all, such implementations often help guide features like this along. -Beth ___ 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
Re: [webkit-dev] scoping Node destruction during DOM modifications
Do we understand what's causing the performance regression? For example, there are other implementation approaches where we try to transfer the last ref rather than churning it or where we could use a free list rather than a vector. I just wonder if there's a way to get the benefits with a lower cost. Adam On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote: We have a lot of code (e.g. in ContainerNode.cpp or any of the editing code) that needs to RefPtr nodes to make sure they're not destroyed due to synchronous events like blur, mutation events, etc. For example, ContainerNode::removeChild needs to RefPtr the parent to make it's not destroyed during a sync event. Currently, we need to write careful code that knows whether any methods it's calling can fire sync events and RefPtrs all the appropriate nodes. I have a proposal to automate this in https://bugs.webkit.org/show_bug.cgi?id=80041. It certainly makes the code cleaner and safer, but it comes at a performance cost in some cases. Basically, any scope that needs to be careful of sync events adds a DOMRemovalScope at the top which keeps nodes from getting destroyed until the scope is destroyed (DOMRemovalScope adds them to a VectorRefPtrNode). In cases where we don't delete nodes, there's no performance impact. In cases where we delete nodes, this is always slower. I uploaded two performance tests to that bug: 1. Set innerHTML = on a node that has half a million children. This test goes from ~166ms to ~172ms on my machine. A 3.6% regression. 2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression. So destroying Nodes during synchronous events fired during a DOM mutation is significantly slower. This case is rare though. I had to think hard to come up with a case where we would hit this. For the most part, nodes don't actually get destroyed due to JS until a garbage collection occurs, which is usually after the event has completed and the DOMRemovalScope has been destroyed. The advantage of this is that it gives a simple way to address a common class of crash and potentially security bugs. The disadvantage of course is the possible performance hit. What do you think? Is this worth trying? Are there better ideas? Ojan ___ 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] scoping Node destruction during DOM modifications
On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote: We have a lot of code (e.g. in ContainerNode.cpp or any of the editing code) that needs to RefPtr nodes to make sure they're not destroyed due to synchronous events like blur, mutation events, etc. For example, ContainerNode::removeChild needs to RefPtr the parent to make it's not destroyed during a sync event. This sounds like a nice feature. I uploaded two performance tests to that bug: 1. Set innerHTML = on a node that has half a million children. This test goes from ~166ms to ~172ms on my machine. A 3.6% regression. 2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression. I'm surprised that we get a 20% regression. Can we try inlining all functions in DOMRemovalProtector and see if that helps? So destroying Nodes during synchronous events fired during a DOM mutation is significantly slower. This case is rare though. I had to think hard to come up with a case where we would hit this. For the most part, nodes don't actually get destroyed due to JS until a garbage collection occurs, which is usually after the event has completed and the DOMRemovalScope has been destroyed. Do we know how common this happens in wild? How rare is it? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] scoping Node destruction during DOM modifications
I agree with Adam's remarks. The safety benefit seems great, but we should investigate ways to get it at less performance cost (ideally no measurable cost). I'm also curious what impact this change has on less micro- but still DOM-oriented benchmarks, such as Dromaeo's DOM tests, Peacekeeper, or the Acid3 secret hidden perf test. I think all of those entail some DOM node destruction although perhaps they do not hit this pattern at all. Regards, Maciej On Mar 1, 2012, at 5:06 PM, Adam Barth wrote: Do we understand what's causing the performance regression? For example, there are other implementation approaches where we try to transfer the last ref rather than churning it or where we could use a free list rather than a vector. I just wonder if there's a way to get the benefits with a lower cost. Adam On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote: We have a lot of code (e.g. in ContainerNode.cpp or any of the editing code) that needs to RefPtr nodes to make sure they're not destroyed due to synchronous events like blur, mutation events, etc. For example, ContainerNode::removeChild needs to RefPtr the parent to make it's not destroyed during a sync event. Currently, we need to write careful code that knows whether any methods it's calling can fire sync events and RefPtrs all the appropriate nodes. I have a proposal to automate this in https://bugs.webkit.org/show_bug.cgi?id=80041. It certainly makes the code cleaner and safer, but it comes at a performance cost in some cases. Basically, any scope that needs to be careful of sync events adds a DOMRemovalScope at the top which keeps nodes from getting destroyed until the scope is destroyed (DOMRemovalScope adds them to a VectorRefPtrNode). In cases where we don't delete nodes, there's no performance impact. In cases where we delete nodes, this is always slower. I uploaded two performance tests to that bug: 1. Set innerHTML = on a node that has half a million children. This test goes from ~166ms to ~172ms on my machine. A 3.6% regression. 2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression. So destroying Nodes during synchronous events fired during a DOM mutation is significantly slower. This case is rare though. I had to think hard to come up with a case where we would hit this. For the most part, nodes don't actually get destroyed due to JS until a garbage collection occurs, which is usually after the event has completed and the DOMRemovalScope has been destroyed. The advantage of this is that it gives a simple way to address a common class of crash and potentially security bugs. The disadvantage of course is the possible performance hit. What do you think? Is this worth trying? Are there better ideas? Ojan ___ 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] scoping Node destruction during DOM modifications
I think my earlier testing was faulty. Now when I test case 2, I get something comparable with and without the patch. If there is a regression, it's below the noise. Running it through a profiler shows a negligible amount of time in the new code. I had tried running it through Dromaeo first, but any performance impact (if there is any) was well below the variance. I can take a stab at running Peacekeeper and Acid3 tomorrow, but I don't have high hopes of getting useful information out of them. My hope with the microbenchmarks was to show worst-case behavior. I expect that in practice this will have no performance impact in the real world. That's a hard statement to prove though. I'll see if I can reduce the variance in my microbenchmarks. On Thu, Mar 1, 2012 at 5:27 PM, Maciej Stachowiak m...@apple.com wrote: I agree with Adam's remarks. The safety benefit seems great, but we should investigate ways to get it at less performance cost (ideally no measurable cost). I'm also curious what impact this change has on less micro- but still DOM-oriented benchmarks, such as Dromaeo's DOM tests, Peacekeeper, or the Acid3 secret hidden perf test. I think all of those entail some DOM node destruction although perhaps they do not hit this pattern at all. Regards, Maciej On Mar 1, 2012, at 5:06 PM, Adam Barth wrote: Do we understand what's causing the performance regression? For example, there are other implementation approaches where we try to transfer the last ref rather than churning it or where we could use a free list rather than a vector. I just wonder if there's a way to get the benefits with a lower cost. Adam On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote: We have a lot of code (e.g. in ContainerNode.cpp or any of the editing code) that needs to RefPtr nodes to make sure they're not destroyed due to synchronous events like blur, mutation events, etc. For example, ContainerNode::removeChild needs to RefPtr the parent to make it's not destroyed during a sync event. Currently, we need to write careful code that knows whether any methods it's calling can fire sync events and RefPtrs all the appropriate nodes. I have a proposal to automate this in https://bugs.webkit.org/show_bug.cgi?id=80041. It certainly makes the code cleaner and safer, but it comes at a performance cost in some cases. Basically, any scope that needs to be careful of sync events adds a DOMRemovalScope at the top which keeps nodes from getting destroyed until the scope is destroyed (DOMRemovalScope adds them to a VectorRefPtrNode). In cases where we don't delete nodes, there's no performance impact. In cases where we delete nodes, this is always slower. I uploaded two performance tests to that bug: 1. Set innerHTML = on a node that has half a million children. This test goes from ~166ms to ~172ms on my machine. A 3.6% regression. 2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression. So destroying Nodes during synchronous events fired during a DOM mutation is significantly slower. This case is rare though. I had to think hard to come up with a case where we would hit this. For the most part, nodes don't actually get destroyed due to JS until a garbage collection occurs, which is usually after the event has completed and the DOMRemovalScope has been destroyed. The advantage of this is that it gives a simple way to address a common class of crash and potentially security bugs. The disadvantage of course is the possible performance hit. What do you think? Is this worth trying? Are there better ideas? Ojan ___ 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] scoping Node destruction during DOM modifications
On Thu, Mar 1, 2012 at 7:18 PM, Ojan Vafai o...@chromium.org wrote: I think my earlier testing was faulty. Now when I test case 2, I get something comparable with and without the patch. If there is a regression, it's below the noise. Running it through a profiler shows a negligible amount of time in the new code. I had tried running it through Dromaeo first, but any performance impact (if there is any) was well below the variance. I can take a stab at running Peacekeeper and Acid3 tomorrow, but I don't have high hopes of getting useful information out of them. That sounds promising. Here's another idea. What if we added ASSERT_NOT_REACHED right before we add the node to m_nodesToKeepAlive. This assertion is hit whenever we destroy a node too early. That should help us identifying code where we're not using RefPtr properly while still preventing such code from introducing security bugs. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
