Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
From: ext Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org Date: Saturday, February 9, 2013 12:52 AM To: Noam Rosenthal noam.rosent...@nokia.commailto:noam.rosent...@nokia.com Cc: rn...@webkit.orgmailto:rn...@webkit.org rn...@webkit.orgmailto:rn...@webkit.org, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly On Fri, Feb 8, 2013 at 3:16 PM, noam.rosent...@nokia.commailto:noam.rosent...@nokia.com wrote: The problem with dynamic features of the web like animations/interactions is that they're non-deterministic, or at least a lot less deterministic than static features of the web like layouts. Ref tests, pixel tests etc. are tools built for deterministic testing: load a file, take a snapshot, compare against a result. Testing an animation (or a filter) needs to feel a lot more dynamic and expressive: Animate green boxes, make sure that they're within a particular range at particular points in time. The tests also have to be deterministic and comprehensive. I am afraid of loosing both with the Render-to-Canvas approach. Can you give concrete examples of the kind of bugs you are hunting, and why testing cannot use the two methods suggested? I did not say they cannot be tested with the two methods suggested :) It's more about a preference to move some of those decisions from the test infrastructure to the test itself, but potentially those bugs could be tested in either way. Examples for bugs I've encountered/reviewed and can use better in-motion testing (note that those are specific to Qt/EFL, but I'm sure there are tons of bugs like this that come up for Apple/Google as well) http://trac.webkit.org/changeset/140825 http://trac.webkit.org/changeset/142112 http://trac.webkit.org/changeset/134953 https://bugs.webkit.org/show_bug.cgi?id=109179 Controlling the clock and programmatically sampling the end result would definitely make those more testable, but of course any progress in this area would be beneficial and my preference to a canvas-based API is more of an opinion. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
On Sat, Feb 9, 2013 at 1:24 AM, noam.rosent...@nokia.com wrote: I did not say they cannot be tested with the two methods suggested :) It's more about a preference to move some of those decisions from the test infrastructure to the test itself, but potentially those bugs could be tested in either way. Examples for bugs I've encountered/reviewed and can use better in-motion testing (note that those are specific to Qt/EFL, but I'm sure there are tons of bugs like this that come up for Apple/Google as well) http://trac.webkit.org/changeset/140825 http://trac.webkit.org/changeset/142112 http://trac.webkit.org/changeset/134953 https://bugs.webkit.org/show_bug.cgi?id=109179 Controlling the clock and programmatically sampling the end result would definitely make those more testable, but of course any progress in this area would be beneficial and my preference to a canvas-based API is more of an opinion. To explain my concerns: Sometime, I look at a failing test, and think: what the f**k is this supposed to test?. Then I have to dig a ton of logs, and finally read the change to understand a the single JS statement in the whole script that make the test useful. This is the situation I am afraid with a solution where pixels would be evaluated from JavaScript. You can test, but you lack visibility why something is correct or incorrect. Text tests, ref-tests and pixel tests have a great readability, you can quickly evaluate their correctness. This is important in my opinion, I don't think we want more opaque output like the RenderTree dump. I am not against your plan if the readability of the tests can be good. I'd be happy to review patches toward testing dynamic changes in webpages. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
From: ext Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org This is the situation I am afraid with a solution where pixels would be evaluated from JavaScript. You can test, but you lack visibility why something is correct or incorrect. Text tests, ref-tests and pixel tests have a great readability, you can quickly evaluate their correctness. This is important in my opinion, I don't think we want more opaque output like the RenderTree dump. I am not against your plan if the readability of the tests can be good. I'd be happy to review patches toward testing dynamic changes in webpages. We're on the same page. I'm afraid of the same thing… Let's talk specifics when a patch is available to review. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] webkit-gem gtk2 installation error
Hi, i am using Fedora. I want to install webkit-gtk-ruby gem but it gives
me error. Also i tried to install gem gtk2 and i couldn't install them. But
i could install rubyzip gem. I added as attach webkit-gtk-ruby error. Can
you help me? Also i had tried without -v option but i couldn't install.
[ebru@dhcppc0 ~]$ sudo gem install -v 0.0.5 gtk-webkit-ruby
Building native extensions. This could take a while...
.
ERROR: Error installing gtk-webkit-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby extconf.rb
checking for -Wall option to compiler... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/bin/ruby
/usr/share/ruby/mkmf.rb:381:in `try_do': The compiler failed to generate an
executable file. (RuntimeError)
You have to install development tools first.
from /usr/share/ruby/mkmf.rb:491:in `block in try_compile'
from /usr/share/ruby/mkmf.rb:443:in `with_werror'
from /usr/share/ruby/mkmf.rb:491:in `try_compile'
from /usr/share/gems/gems/glib2-1.1.9/lib/mkmf-gnome2.rb:27:in `block
in try_compiler_option'
from /usr/share/ruby/mkmf.rb:790:in `block in checking_for'
from /usr/share/ruby/mkmf.rb:284:in `block (2 levels) in postpone'
from /usr/share/ruby/mkmf.rb:254:in `open'
from /usr/share/ruby/mkmf.rb:284:in `block in postpone'
from /usr/share/ruby/mkmf.rb:254:in `open'
from /usr/share/ruby/mkmf.rb:280:in `postpone'
from /usr/share/ruby/mkmf.rb:789:in `checking_for'
from /usr/share/gems/gems/glib2-1.1.9/lib/mkmf-gnome2.rb:26:in
`try_compiler_option'
from /usr/share/gems/gems/glib2-1.1.9/lib/mkmf-gnome2.rb:31:in `top
(required)'
from /usr/share/rubygems/rubygems/custom_require.rb:60:in `require'
from /usr/share/rubygems/rubygems/custom_require.rb:60:in `rescue in
require'
from /usr/share/rubygems/rubygems/custom_require.rb:35:in `require'
from extconf.rb:4:in `main'
Gem files will remain installed in
/usr/local/share/gems/gems/gtk-webkit-ruby-0.0.5 for inspection.
Results logged to
/usr/local/share/gems/gems/gtk-webkit-ruby-0.0.5/ext/webkit/gem_make.out
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-gem gtk2 installation error
I installed necessary all packages i think. I installed them sudo yum install ruby-devel sudo yum install rubygem-gtk2-devel sudo yum install webkitgtk-devel sudo yum install ruby-gnome2-devel 2013/2/9 Ebru Akagunduz ebru.akagun...@gmail.com Hi, i am using Fedora. I want to install webkit-gtk-ruby gem but it gives me error. Also i tried to install gem gtk2 and i couldn't install them. But i could install rubyzip gem. I added as attach webkit-gtk-ruby error. Can you help me? Also i had tried without -v option but i couldn't install. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
Since people seem to agree that this is a good problem to solve, I've created a bug for it: https://bugs.webkit.org/show_bug.cgi?id=109356 I can't promise to fix it myself right this moment as I'm spread a bit too thin, but if someone wants to help or pick it up before I get to it please feel free :) Noam From: ext Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org Date: Saturday, February 9, 2013 10:57 AM To: Noam Rosenthal noam.rosent...@nokia.commailto:noam.rosent...@nokia.com Cc: rn...@webkit.orgmailto:rn...@webkit.org rn...@webkit.orgmailto:rn...@webkit.org, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly On Sat, Feb 9, 2013 at 1:24 AM, noam.rosent...@nokia.commailto:noam.rosent...@nokia.com wrote: I did not say they cannot be tested with the two methods suggested :) It's more about a preference to move some of those decisions from the test infrastructure to the test itself, but potentially those bugs could be tested in either way. Examples for bugs I've encountered/reviewed and can use better in-motion testing (note that those are specific to Qt/EFL, but I'm sure there are tons of bugs like this that come up for Apple/Google as well) http://trac.webkit.org/changeset/140825 http://trac.webkit.org/changeset/142112 http://trac.webkit.org/changeset/134953 https://bugs.webkit.org/show_bug.cgi?id=109179 Controlling the clock and programmatically sampling the end result would definitely make those more testable, but of course any progress in this area would be beneficial and my preference to a canvas-based API is more of an opinion. To explain my concerns: Sometime, I look at a failing test, and think: what the f**k is this supposed to test?. Then I have to dig a ton of logs, and finally read the change to understand a the single JS statement in the whole script that make the test useful. This is the situation I am afraid with a solution where pixels would be evaluated from JavaScript. You can test, but you lack visibility why something is correct or incorrect. Text tests, ref-tests and pixel tests have a great readability, you can quickly evaluate their correctness. This is important in my opinion, I don't think we want more opaque output like the RenderTree dump. I am not against your plan if the readability of the tests can be good. I'd be happy to review patches toward testing dynamic changes in webpages. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2013, at 2:33 PM, Darin Fisher da...@chromium.org wrote: I would recommend minimizing the re-architecture of WebCore as you are in the early stages of upstreaming. It seems like you already have a working port that you could simply upstream. You could then work with others in the community to introduce new concepts to WebCore with the full disclosure of code as an aide to the process. Another option might be to open source the entire thing as a branch somewhere. After the initial upstreaming or sharing of code is complete, you could then catalog all of the warts. The fact that isMainThread returns true when called on more than one thread would be one such wart. I can imagine a meta bug tracking all of these warts. This would make it a lot easier for others to understand the overall change in direction needed for WebKit to properly support the iOS port. That's approximately what we're planning to do. We are upstreaming incrementally, starting with simple pieces, and documenting issues. The bug that sparked this thread was a relatively change to isMainThread(), plus a function rename, and we are no longer asking for the function rename. It will likely be a dozen line patch touching a single mac/ios-specific file. We'd really like to fully upstream the simpler components like WTF (where the changes are all simple and targeted) even if we can't as easily do WebCore (where there may be more complex and controversial diffs). From what you've said, it sounds like this issue doesn't apply to WebKit2 on iOS. Perhaps we should focus on merging WebKit2 into trunk and delay having to worry about running WebCore on multiple interlocking threads. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
The existing pauseAnimation DRT API can stop an animation mid-flight, to allow for reliable snapshotting. Why isn't this enough? Simon On Feb 9, 2013, at 8:44 AM, noam.rosent...@nokia.com wrote: Since people seem to agree that this is a good problem to solve, I've created a bug for it: https://bugs.webkit.org/show_bug.cgi?id=109356 I can't promise to fix it myself right this moment as I'm spread a bit too thin, but if someone wants to help or pick it up before I get to it please feel free :) Noam From: ext Benjamin Poulain benja...@webkit.org Date: Saturday, February 9, 2013 10:57 AM To: Noam Rosenthal noam.rosent...@nokia.com Cc: rn...@webkit.org rn...@webkit.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly On Sat, Feb 9, 2013 at 1:24 AM, noam.rosent...@nokia.com wrote: I did not say they cannot be tested with the two methods suggested :) It's more about a preference to move some of those decisions from the test infrastructure to the test itself, but potentially those bugs could be tested in either way. Examples for bugs I've encountered/reviewed and can use better in-motion testing (note that those are specific to Qt/EFL, but I'm sure there are tons of bugs like this that come up for Apple/Google as well) http://trac.webkit.org/changeset/140825 http://trac.webkit.org/changeset/142112 http://trac.webkit.org/changeset/134953 https://bugs.webkit.org/show_bug.cgi?id=109179 Controlling the clock and programmatically sampling the end result would definitely make those more testable, but of course any progress in this area would be beneficial and my preference to a canvas-based API is more of an opinion. To explain my concerns: Sometime, I look at a failing test, and think: what the f**k is this supposed to test?. Then I have to dig a ton of logs, and finally read the change to understand a the single JS statement in the whole script that make the test useful. This is the situation I am afraid with a solution where pixels would be evaluated from JavaScript. You can test, but you lack visibility why something is correct or incorrect. Text tests, ref-tests and pixel tests have a great readability, you can quickly evaluate their correctness. This is important in my opinion, I don't think we want more opaque output like the RenderTree dump. I am not against your plan if the readability of the tests can be good. I'd be happy to review patches toward testing dynamic changes in webpages. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
Oops, forgot to reply to the list. From: Noam Rosenthal noam.rosent...@nokia.commailto:noam.rosent...@nokia.com From: ext Simon Fraser simon.fra...@apple.commailto:simon.fra...@apple.com The existing pauseAnimation DRT API can stop an animation mid-flight, to allow for reliable snapshotting. Why isn't this enough? I would say that the main things that are missing are: 1. Sample and compare several images in the same test 2. Sample images heuristically, e.g. sample that a green box is close enough to a particular location – A full ImageDiff is very rigid in that way. 3. Sample images mid-flight without pausing. Pausing can mess with animation timing and thus skew the results. I don't have a full list of what's missing – but I know for sure that when trying to hunt mid-flight bugs in the past I was not able to create sufficient tests with the current DRT tools. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Feb 9, 2013, at 10:11 AM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2013, at 2:33 PM, Darin Fisher da...@chromium.org wrote: I would recommend minimizing the re-architecture of WebCore as you are in the early stages of upstreaming. It seems like you already have a working port that you could simply upstream. You could then work with others in the community to introduce new concepts to WebCore with the full disclosure of code as an aide to the process. Another option might be to open source the entire thing as a branch somewhere. After the initial upstreaming or sharing of code is complete, you could then catalog all of the warts. The fact that isMainThread returns true when called on more than one thread would be one such wart. I can imagine a meta bug tracking all of these warts. This would make it a lot easier for others to understand the overall change in direction needed for WebKit to properly support the iOS port. That's approximately what we're planning to do. We are upstreaming incrementally, starting with simple pieces, and documenting issues. The bug that sparked this thread was a relatively change to isMainThread(), plus a function rename, and we are no longer asking for the function rename. It will likely be a dozen line patch touching a single mac/ios-specific file. We'd really like to fully upstream the simpler components like WTF (where the changes are all simple and targeted) even if we can't as easily do WebCore (where there may be more complex and controversial diffs). From what you've said, it sounds like this issue doesn't apply to WebKit2 on iOS. (1) What WebKit2 on iOS? We have not announced or shipped such a thing. The code used by MobileSafari, and by third party apps like the embedded browser in Twitter, or Chrome for iOS is a WebKit1 based port. (2) You might reasonably guess that WebKit2 on iOS is a plausible future direction. If we did do it, then as on Mac we would consider it a requirement for it to use the same binaries for WebCore and lower (though we'd turn off the Web Thread at runtime). Perhaps we should focus on merging WebKit2 into trunk and delay having to worry about running WebCore on multiple interlocking threads. This suggestion is approximately equivalent to let's not merge yet, for reasons stated above. There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. Regards, Maciej P.S. Running WebCore on interlocking threads is a needlessly scary way to describe what iOS WebKit does. There is no complex fine-grained locking or actual parallel execution. It's more like what would happen if you ran WebKit on a GCD dispatch queue or a thread in a userspace M:N threading library, instead of on an underlying OS-level thread (really it's a restricted subset of that). As such, it has very little impact on WebCore and below. Mainly it just requires that the threading primitives have an appropriate platform implementation on iOS. For anyone interested in learning more about this, I think Ben had the best high-level explanation: https://bugs.webkit.org/show_bug.cgi?id=109071#c14. We can also provide more detail if desired. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-gem gtk2 installation error
I don't mean to be rude, but please let's keep this kind of questions in webkit-help. -- Bye, Michelangelo Il giorno Feb 9, 2013, alle ore 8:43 AM, Ebru Akagunduz ebru.akagun...@gmail.com ha scritto: I installed necessary all packages i think. I installed them sudo yum install ruby-devel sudo yum install rubygem-gtk2-devel sudo yum install webkitgtk-devel sudo yum install ruby-gnome2-devel 2013/2/9 Ebru Akagunduz ebru.akagun...@gmail.com Hi, i am using Fedora. I want to install webkit-gtk-ruby gem but it gives me error. Also i tried to install gem gtk2 and i couldn't install them. But i could install rubyzip gem. I added as attach webkit-gtk-ruby error. Can you help me? Also i had tried without -v option but i couldn't install. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Sat, Feb 9, 2013 at 3:01 PM, James Robinson jam...@google.com wrote: http://trac.webkit.org/changeset/141812 ( https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking to the AtomicString table in order to support the iOS WebKit threading model. If parallel execution is not possible, why would this need locking? That code does not make AtomicString thread safe in any way. If I remember correctly, that code is related to races at initializations. I can dig the history on Monday if you'd like. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. For what my opinion is worth (probably near zero for a lot of you), I would like to see you guys merge sooner rather than later, even if it leads to awkwardness that needs cleanup. Over the years there has been a nonzero amount of friction due to the iOS port not being upstreamed, and I think it would be beneficial to WebKit as a whole to fix that sooner rather than later. And it seems more likely to me that upstream first, then decide how to re-architect as needed is going to result in high-quality discussions and designs, as opposed to figure out in private how to re-architect before upstreaming, which runs the risk of just never bothering to upstream at all. There is real compromise, and perhaps humility, needed from all sides to make such a task successful. I am reminded of Eric's recent email where he pleaded for more of an explicit effort to civility towards each other. Perhaps this is an opportunity for us to practice that effort. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
On Sat, Feb 9, 2013 at 1:57 AM, Benjamin Poulain benja...@webkit.org wrote: On Sat, Feb 9, 2013 at 1:24 AM, noam.rosent...@nokia.com wrote: I did not say they cannot be tested with the two methods suggested :) It's more about a preference to move some of those decisions from the test infrastructure to the test itself, but potentially those bugs could be tested in either way. Examples for bugs I've encountered/reviewed and can use better in-motion testing (note that those are specific to Qt/EFL, but I'm sure there are tons of bugs like this that come up for Apple/Google as well) http://trac.webkit.org/changeset/140825 http://trac.webkit.org/changeset/142112 http://trac.webkit.org/changeset/134953 https://bugs.webkit.org/show_bug.cgi?id=109179 Controlling the clock and programmatically sampling the end result would definitely make those more testable, but of course any progress in this area would be beneficial and my preference to a canvas-based API is more of an opinion. To explain my concerns: Sometime, I look at a failing test, and think: what the f**k is this supposed to test?. Then I have to dig a ton of logs, and finally read the change to understand a the single JS statement in the whole script that make the test useful. This is the situation I am afraid with a solution where pixels would be evaluated from JavaScript. You can test, but you lack visibility why something is correct or incorrect. Text tests, ref-tests and pixel tests have a great readability, you can quickly evaluate their correctness. This is important in my opinion, I don't think we want more opaque output like the RenderTree dump. I am not against your plan if the readability of the tests can be good. I'd be happy to review patches toward testing dynamic changes in webpages. A counter-argument, of course, that there are a lot of pixel tests that would be a lot better as text-only tests that were verifying certain aspects of how the page rendered programmatically. Perhaps -- and this is a tangent to this thread -- we could also investigate ways of writing tests that did render pngs but told NRWT to ignore them (e.g., dumpAsTextAndIgnoredImage() or something), or conveyed which parts of the image were important ... -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Feb 9, 2013, at 3:01 PM, James Robinson jam...@google.com wrote: On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: P.S. Running WebCore on interlocking threads is a needlessly scary way to describe what iOS WebKit does. There is no complex fine-grained locking or actual parallel execution. It's more like what would happen if you ran WebKit on a GCD dispatch queue or a thread in a userspace M:N threading library, instead of on an underlying OS-level thread (really it's a restricted subset of that). As such, it has very little impact on WebCore and below. Mainly it just requires that the threading primitives have an appropriate platform implementation on iOS. http://trac.webkit.org/changeset/141812 (https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking to the AtomicString table in order to support the iOS WebKit threading model. If parallel execution is not possible, why would this need locking? This is one of the few pieces of code that gets touched for other threads, mainly because pieces of WebCore get used for some non-Web-content-related drawing. I'll have to do research if you want to know in more detail. Because it's the weekend and I have the copious free time, I will go over the full set of diffs and post a full list of the threading-model-related changes that are required in WebCore and below. I expect it to be surprisingly short and low-impact, but I will post it even if it looks grim. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
Hi Peter, On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote: On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. For what my opinion is worth (probably near zero for a lot of you), I would like to see you guys merge sooner rather than later, even if it leads to awkwardness that needs cleanup. Over the years there has been a nonzero amount of friction due to the iOS port not being upstreamed, and I think it would be beneficial to WebKit as a whole to fix that sooner rather than later. And it seems more likely to me that upstream first, then decide how to re-architect as needed is going to result in high-quality discussions and designs, as opposed to figure out in private how to re-architect before upstreaming, which runs the risk of just never bothering to upstream at all. There is real compromise, and perhaps humility, needed from all sides to make such a task successful. I am reminded of Eric's recent email where he pleaded for more of an explicit effort to civility towards each other. Perhaps this is an opportunity for us to practice that effort. I really appreciate you saying that. I feel the same way. For years we've been saying that we need to fix N different things before upstreaming, and in the end we concluded that it was just delaying us from upstreaming at all. And we concluded that cleaning up some of the questionable choices in the open would lead to a better final outcome. At the same time, I think some scrutiny of what we are doing is fair, so I'll try to explain the threading issues in a bit more detail to the extent I can. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
