Re: [webkit-dev] Turning CSS Variables Off
On 16 May 2013 17:50, Sergio Villar Senin svil...@igalia.com wrote: Yeah I know. That's why I tried to get in contact with Luke Macpherson, the author of the current implementation, but it looks like he isn't working in Chromium any more. Alan Cutter is the maintainer of CSS Variables in Blink. He's finishing up the CSSOM integration, which was the missing thing at the time of the fork. The spec (now called CSS Custom Properties) is now at Last Call ( http://dev.w3.org/csswg/css-variables/), so spec-wise, things are unlikely to change, unless someone pipes up Right Now. If people have concerns about the specification, please do raise them over at www-style. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Hi Maciej! On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote: It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. For b), does 'default' include an Xcode install? From my memory of setting up a Mac dev box Xcode was needed to compile. mike On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. Cheers, Maciej ___ 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] Int/FloatPoint and Int/FloatSize
On 4 January 2013 16:15, Simon Fraser simon.fra...@apple.com wrote: Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? Rename that to DynamicallyResizableRandomlyAccessibleT, because, you know, Euclid got there first :P ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]
On 16 November 2012 09:59, Ryosuke Niwa rn...@webkit.org wrote: While I don’t want to further agitate the issue or go off on a tangent, and agree that we must address the security aspect before getting rid of RenderArena, only WebKit reviewers can r- patches written by other contributors. You’re not even supposed to set r- on your own patches. See http://www.webkit.org/coding/commit-review-policy.html I see that page says 'Note that you should not put r+ nor r- on patches in such unofficial reviews' with respect to a non-reviewer doing a shadow review. I can't see the extrapolation from that to 'you can't r- your own patches'. I thought r-'ing your own patch was a relatively common practice when uploading a WIP patch, as a signal that 'I have no intention of landing this patch', and as a courtesy so a reviewer will not waste any time looking at it (unless specifically asked). I don't see why I wouldn't be allowed to r- my own patch? mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Time to remove LIKELY and UNLIKELY macros?
On 2 October 2012 16:29, Maciej Stachowiak m...@apple.com wrote: Note, despite the stackoverflow thread cited, I would be highly surprised if static branch predicition had no effect ever, even on modern architectures. While recent intel CPUs have very good dynamic branch prediction, the basic block reordering should still have a significant impact in some cases due to cache effects. Aside: interestingly, the Core2 family of CPUs doesn't do 'static branch prediction' in the traditional sense. When they encounter a branch not already in the BTB, a BTB index is assigned to it. The prediction now proceeds as though it were dynamic - meaning that this first time, it predicts based on the previous data in that index. That is, it's effectively a 50% chance of taken/not taken the first time the branch is encountered (source: http://www.agner.org/optimize/microarchitecture.pdf, Section 3.15). mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?
On 2 October 2012 04:30, Oliver Hunt oli...@apple.com wrote: That's what the ASSERT_UNUSED(variable, assertion) macro is for :D fwiw, my first reading of that name had me thinking it meant 'ASSERT that this variable is unused' in the vein of macros I've seen in other places like ASSERT_TRUE, ASSERT_NOT_NULL etc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?
ASSERT_WITH_OTHERWISE_UNUSED. On 2 October 2012 10:51, Ryosuke Niwa rn...@webkit.org wrote: How about ASSERT_OR_UNUSED or ASSERT_USING_UNUSED? On Mon, Oct 1, 2012 at 5:23 PM, Darin Adler da...@apple.com wrote: On Oct 1, 2012, at 5:21 PM, Mike Lawther mikelawt...@google.com wrote: my first reading of that name had me thinking it meant 'ASSERT that this variable is unused' in the vein of macros I've seen in other places like ASSERT_TRUE, ASSERT_NOT_NULL etc. Yes, even though I named the macro I have had the same thought often. I love the macro, but a better name, even if a bit longer, would be welcome. If we can think of one we can fix this with a quick global replace. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] String::operator+= considered harmful
On 5 September 2012 09:44, Dirk Schulze dschu...@adobe.com wrote: It is very likely that even future code will land with this operator instead of StringBuilder. Not if Adam removes the operator as he proposed earlier :) If operator+= cannot be made sufficiently efficient, we could always leave the operator there, but have it ASSERT with a message saying to use StringBuilder. mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] String::operator+= considered harmful
If operator+= cannot be made sufficiently efficient, we could always leave the operator there, but have it ASSERT with a message saying to use StringBuilder. Please not this. Failing at compile time is much better than failing at runtime in debug builds only. I was only half serious, figuring that leaving out operator+= would probably tempt a future contributor to fix it :) Using #error would of course be much better if this path were to be followed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] editbugs permission
Hi there, I'd like to ask for EditBugs permission for dstockw...@chromium.org, who has already landed a couple of patches and is helping us triage bugs. thanks! mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
I'm the guy that added css3/calc tests. I did so because I not all my tests are 'text only' tests, but I still wanted them all together. My understanding was that the 'fast' directory was intended for 'text only' tests only. Does having the 'fast' directory still serve a useful purpose? I reckon the original intent could be pushed into the tools, eg have a 'new-run-webkit-tests --fast', which will only run text-only tests. Then the developer adding new tests doesn't have to worry about where to put them. mike On 11 June 2012 18:57, Ryosuke Niwa rn...@webkit.org wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
On 19 March 2012 22:44, Alexis Menard alexis.men...@openbossa.org wrote: Hi, On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. trac is down today for us. bugs.webkit.org is also down with this error : I'm also seeing them down with the same symptoms from my home connection in Sydney. Traceroutes appended: traceroute to bugs.webkit.org (17.254.20.233), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 2.607 ms 0.875 ms 0.652 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.653 ms 18.283 ms 18.731 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 18.890 ms 18.652 ms 18.288 ms 4 syd-sot-ken2-crt2-ge-9-0-0 (203.29.135.173) 17.809 ms 19.238 ms 18.143 ms 5 te9-1.ccr02.lax04.atlas.cogentco.com (38.104.210.53) 227.246 ms 207.515 ms 207.168 ms 6 te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69) 207.495 ms te0-3-0-7.ccr21.lax01.atlas.cogentco.com (154.54.1.9) 208.140 ms 208.054 ms 7 te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 221.802 ms te9-3.mpd01.sjc01.atlas.cogentco.com (154.54.25.186) 222.440 ms te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 374.174 ms 8 38.104.134.70 (38.104.134.70) 220.819 ms 220.666 ms 220.254 ms 9 border1.t7-1-bbnet1.sje.pnap.net (66.151.144.4) 391.199 ms 292.140 ms 255.343 ms 10 * * * 11 * * * [etc] traceroute to trac.webkit.org (17.254.20.241), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 3.605 ms 0.754 ms 3.930 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.515 ms 18.350 ms 18.426 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 19.037 ms 18.247 ms 18.236 ms 4 syd-sot-ken2-crt1-ge-9-0-0 (202.7.171.173) 18.632 ms 18.394 ms 18.429 ms 5 ix-8-3-0-0.tcore2.lvw-losangeles.as6453.net (64.86.252.125) 200.775 ms 200.856 ms 200.622 ms 6 xe-8-0-0.edge1.losangeles9.level3.net (4.68.62.117) 201.657 ms 201.147 ms 200.371 ms 7 vlan60.csw1.losangeles1.level3.net (4.69.144.62) 203.967 ms vlan80.csw3.losangeles1.level3.net (4.69.144.190) 200.859 ms vlan90.csw4.losangeles1.level3.net (4.69.144.254) 205.358 ms 8 ae-83-83.ebr3.losangeles1.level3.net (4.69.137.41) 203.072 ms 200.655 ms ae-93-93.ebr3.losangeles1.level3.net (4.69.137.45) 200.738 ms 9 ae-3-3.ebr1.sanjose1.level3.net (4.69.132.9) 211.694 ms 211.626 ms 212.040 ms 10 ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 221.184 ms ae-61-61.csw1.sanjose1.level3.net (4.69.153.2) 211.839 ms ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 218.424 ms 11 ae-41-80.car1.sanjose2.level3.net (4.69.152.139) 212.528 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 212.445 ms ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 212.433 ms 12 * * * 13 * * * [etc] mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] optimising png files in LayoutTests - an experiment
Hi guys,
Just thought I'd share the results of an experiment I did in optimising the
png files in LayoutTests.
I used a tool on Mac called ImageOptim (http://imageoptim.pornel.net/)
which tries a set of different png lossless optimising tools (like pngcrush
- I also downloaded and included PNGOUT). Note that this strips out some of
the stuff we need, like the hash, so if doing this for real we'd have to
watch out for that.
My results were:
Before:
$ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
total}'
1220535840
Test:
$ find LayoutTests/ | grep png$ | xargs open -a ImageOptim.app
After:
$ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
total, 1220535840 - total}'
937198328 283337512
So this has saved ~280MB (~23% of the original size).
Based on this, it seems worthwhile to include a png optimiser somewhere in
the patch upload/submit toolchain, and also (separately) to optimise the
existing pngs.
Thoughts?
mike
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
And for git users: http://trac.webkit.org/wiki/UsingGitWithWebKit (there is a section on setting mime-types via subversion's config file). On 9 January 2012 13:44, Benjamin Poulain benja...@webkit.org wrote: On Sun, Jan 8, 2012 at 6:15 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Some more info :) http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit 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] Fwd: Re: Painting Phases
There is a good video somewhere that Eric Seidel describes the rendering inside WebKit that covers this. I think http://www.youtube.com/watch?v=RVnARGhhs9w is the right one. mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
