Re: [webkit-dev] Code Style: Opinion on returning void
On Thu, Feb 21, 2019 at 12:31 PM Darin Adler wrote: > I tried not to weigh in on this, but my view on the materials we should > use to build the bike shed must be shared! > > Generally it seems neat to be able to make the code slightly more tight > and terse by merging the function call and the return into a single > statement. > > Other than not being accustomed to it, I have noticed three small things I > don’t like about using “return” with a call to a void-returning function. > > - You can’t use this idiom when you want to ignore the result of a > function, only if the function actually returns void. Often functions are > designed with ignorable and often ignored return values. For example, it’s > common to call something that might fail and have a good reason to ignore > whether it failed or not. The idiom we are discussing requires treating > those functions differently from ones that return void. If you refactor so > that a function now returns an ignorable return value you need to visit all > the call sites using return and change them into the two line form. > That works, you just have to spell it `return (void)non_void_fun();` :D > > - It works for return, but not for break. I’ve seen at least one case > where someone filled a switch statement with return statements instead of > break statements so they could use this more-terse form. Now if we want to > add one line of code after that switch, we need to convert all those cases > into multi-line statements with break. > > - Unless it’s mandatory, it’s a case where two programmers can make > different style choices. If both forms are acceptable, then it introduces a > little bit of disorder into our code. > > One thing I like about it is that since “pass along the return value from > this inner function to this outer function” can be written this way, the > code can then survive refactorings where both the inner and outer functions > might gain or lose the return value. > > — Darin > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Fri, Mar 20, 2015 at 9:56 AM, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Web Utility Belt With Useful Behavior. Simon ___ 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] Ports not building as C++11?
FYI: In gcc 4.7, things like foo%PRIuS are hard errors due to user-defined literals (it's a disablable warning in clang and gcc4.8, and gcc4.6 is fine since it doesn't implement user-defined literals yet), and some system headers (dbus1.0, dbus1.2, probably others) contain code like that. I'd encourage you to try actually building WebKit in c++11 mode with your port to check if you run into anything like that. Nico On Mon, Jul 29, 2013 at 10:42 AM, Patrick East patri...@bsquare.com wrote: There is support for C++11 on Windows Embedded Compact 2013 using the newer VC11 compiler, but for CE 5, 6, or WEC 7 they will not be able to support it since they are limited to the VC9 compiler. Afaik there doesn’t appear to be any plans from Microsoft to back-port the newer compiler and run time to support older versions of CE. ** ** I realize that CE 5, 6, and 7 are probably not top priorities for the community, but these changes will basically force dropping support for those platforms. We do have some interest in keeping WebKit working for our downstream build, so if it’s possible to make this change over to using C++11 in a way that can allow for building without the new features that would be ideal. If there is anything we can do that help make this happen let me know. ** ** Thanks! ** ** *Patrick East* | Software Engineer +1 425.519.5912 | patri...@bsquare.com Bsquare │Forging Smart Connections www.bsquare.com ** ** ** ** ** ** *From:* webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Brent Fulgham *Sent:* Saturday, July 27, 2013 3:04 PM *To:* Anders Carlsson *Cc:* WebKit Development *Subject:* Re: [webkit-dev] Ports not building as C++11? ** ** The only platform I know cannot support C++11 is WinCE, and that port is in favor of making the move to C++11 in anticipation of updated build tools from Microsoft. ** ** What other platform are we talking about here? The GNU compilers have supported C++11 for a long time. ** ** -Brent Sent from my iPhone On Jul 26, 2013, at 8:12 PM, Anders Carlsson ander...@apple.com wrote:** ** ** ** On Jul 26, 2013, at 8:09 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Friday 26 July 2013, Anders Carlsson wrote: Hi everyone, when Oliver landed his “let’s break everything” patches in JSC the other day, I noticed that some of the follow-up build fixes by other ports were removing use of C++11 features (mainly nullptr). Are there any ports that aren’t building as C++11? If so, why not? Yes, and because C++11 is not supported on all the platforms we support. * *** ** ** Could you please elaborate? What compilers are you using? We don't all have the option to not care about the platforms of a certain fruit themed vendor's 1 or 2 year old operating systems. ** ** I don’t think this comment adds anything constructive. ** ** Thanks, - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?
On Wed, Mar 27, 2013 at 12:05 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Daniel, On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell brat...@opera.comwrote: As an experiment we took the (chromium) project webcore_dom, that normally compiles in 56 seconds in Windows on a generic computer and fixed it. Removing the many include paths in the build system and instead specifying the path in the include directives changed that to 42 seconds, a 25% reduction. I thought that much of this was supposed to be addressed by the use of precompiled headers. Presumably, if the header files are properly incorporated into the PCH, shouldn't any gains from relative paths be small? Obviously your statistic says otherwise, but I'm not sure that a single test on a single system is definitive proof of anything. I thought PCHs are mostly for system headers that don't change often ( https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/WebCorePrefix.hq=WebCorePrefixsq=package:chromiumtype=cs), else every .h change would require recompiling _all_ cc files, no? Did you run the test multiple times to get a feel for how reproducible the improvements was? I know I have fooled myself in the past into thinking I had improved something, only to discover that unrelated computer activity (e.g., backups, virus scans, etc.) were contributing to slow build times. -Brent ___ 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] Compiling WebKit up to 25% faster in Windows?
On Tue, Mar 26, 2013 at 4:51 PM, Daniel Bratell brat...@opera.com wrote: Den 2013-03-26 21:20:10 skrev Dirk Pranke dpra...@chromium.org: If we have consensus that we should just switch to paths relative to Source (or maybe a couple different options), that would be (IMO) a big win. It sounds like Daniel co. have already done the big bang conversion. Not the whole conversion, no. Just enough to confirm the suspicion that it affects compile time in Windows. As other people in the thread have mentioned there are some tricky areas so before investing too much time in this, it seemed to be best to check with people with longer experience of the code if there was something we've missed. Though the conversion is scripted so it can possibly be applied to large portions of the source code and then the tricky areas can be manually fixed. Can you share your scripts, so that we can measure how this changes things on other platforms? Thanks! Nico /Daniel __**_ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/**mailman/listinfo/webkit-devhttps://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] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Tue, Jan 22, 2013 at 2:22 AM, Nico Weber tha...@chromium.org wrote: On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber tha...@chromium.org wrote: On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel e...@webkit.org wrote: Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. If you build WebKit/chromium on Linux (i.e. Chromium/Linux and Chromium/Android), you're now using ninja. The Chromium Linux Release and Chromium Android Release build bots seem to be working fine. Admire the exciting build output: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio Let us know if anything is not working for you. (If you must use make, you can pass --no-ninja to update-webkit, and build-webkit will use make again. If you do this, please let me know why.) Chromium/Mac webkit builds now uses ninja by default too. The bot's build output is now a little more concise: http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio On my laptop, full builds are 10% faster and empty builds (the minimum time you need to wait for a build) are 30x as fast. If you still need xcodebuild, you can pass --no-ninja to update-webkit. Please let us know if and why you do this. Nico ps: Switching Chromium/Windows is blocked on http://crbug.com/169945, so it probably won't happen soon. …and windows is now done, too. Thanks to dpranke for helping with this! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code
Going once, going twice… https://bugs.webkit.org/show_bug.cgi?id=109501 On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig wei...@apple.com wrote: Sounds good to me as well. -Sam On Jan 30, 2013, at 3:54 PM, Nico Weber tha...@chromium.org wrote: Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ 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] Common build system (was Re: WebKit Wishes)
http://www.haskell.org/haskellwiki/Wadlers_Law On Tue, Feb 5, 2013 at 12:16 PM, Eric Seidel e...@webkit.org wrote: I'm curious if YAML was ever considered? I have very limited experience with YAML, except for Google App Engine config files. It's very python parse-able? :) On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote: You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote: Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. You can also look at the build output from the chromium bots. Empty build in 1s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio Build with a few files changed in 15s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio …and this is on fairly slow bots. On my SSD-equipped laptop, I can do incremental rebuilds of all of chrome after touching one (cpp or mm) file in 2-6s. Adam On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen kbal...@webkit.org wrote: I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you actually edited and need to be rebuilt. What could help here is to devide WebCore into smaller parts, like the ongoing work of extracting Platform. Maybe the next logical candidate could be svg (I don't have real knowledge about how feasible it is). Note that I don't come up with qmake because I would like to recommend it as the one and only build system (in fact it has a ridiculously inconvenient syntax, and a lot of bugs), just as an example. With Cmake fast incremental rebuilds are also possible, maybe in a bit more complicated way. When working with the EFL port I found a quick rule for WebKit2 in the generated makefile. Although the makefiles are usually call back to Cmake, and make is not faster than build-webkit, if you use the special fast target, which is something like eflWebKit/fast (i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check dependencies but just rebuild the files that have changed. I did not find a similar thing for WebCore, I guess because it is not built as a shared library. What I dislike in Cmake is that I am disappointed by how slow a normal incremental build with it (i.e. build-webkit). qmake is not faster at all, but it generate plain makefiles that typically no call back to qmake if not specified explicitly to do so, and directly calling make is faster, yet it can handle most of the non-trivial changes, for example editing a generator file. I don't know gyp, so I wonder about how would it do in this comparison (but I guess it generates simple makefiles as well, so it's similar than qmake in this manner.) I hope I added something to this conversation that is worth to consider with my late nightly brain dump. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen kbal...@webkit.org wrote: I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
This is a lovely discussion to have every now and then :-) Maybe the file add/move/delete tool that someone wrote could land without xcode support for now? Then the pain of moving files is reduced to two systems (xcode and everyone else), and that's something that's at least tractable. Nico On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer par...@paroga.com wrote: Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak: On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote: Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa: On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote: Another option is to add a webkit-patch command for modifying the build files. That way, the syntax doesn't need to be overly human friendly. There was also some attempt to write a tool to add files automatically: https://bugs.webkit.org/show_bug.cgi?id=61772 I would expect that such a tool becomes easier if it would only modify one source of truth and generates all other artifacts such as Xcode projects from it. I don't want build file's syntax to be so human unfriendly that I need a tool for it. Often times, these syntax problems can be improved dramatically by simple changes. e.g. we had a similar discussion about TestExpectation syntax, and I'm much happier with the new syntax even though the new syntax is functionally equivalent to the old one, and two syntaxes are very similar. On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote: I’ve experimented with this in the past and you’re right that it shouldn’t be particularly difficult to do. However, I suspect that the task would be similar in scope to defining an improved syntax for gyp. And if the syntax is the primary sticking point with gyp then it’d seem preferable to tackle initially. Yeah. In fact, we can just come up with whatever syntax we like and convert it to the existing gyp format if the syntax was the biggest issue. Do we want to define the whole build system (including information how to invoke the generators) with the new system, or is a simple list for the input files sufficient? IMHO adding a new generator build step happens very rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) into new files. Then GYP and CMake can read them and generate the build system out of them directly (like they to already today) instead of listing the files in the *.gpyi and *.cmake. This might work for other systems like qmake too. For XCode we can maybe have a template XCode project and generate the work XCode project with a script. This script then only need to fill in the files from the input file list into the template XCode project. Defining the feature flags can be done like Maciej suggested with Port.h files. I think it would be better to adapt an existing meta build system to our needs than to make one from scratch, unless we find that completely impractical. In particular, gyp and cmake both know how to handle generated sources, and while it may not be super common to make a new type of generated source, it's bad for hackability of the project of doing so is super hard. We get a lot of hackability benefits from using various kinds of generated sources, many first introduced in the days when we had a lot fewer build systems. So in my mind, they are already ahead of a hypothetical simple system. Do you want to kick the requirements of the smaller ports from trunk or do you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where CMake/GYP is not an option. It could certainly make sense for us to add Autotools and Qmake generators to GYP; I'm less certain if a CMake generator makes much sense, but I haven't thought about it as much. I'm not super familiar with any of these three tools, so I could be dead wrong. I completely agree that creating a new meta meta build system isn't a good idea, but sharing the common parts (which reduce the daily productivity) might be a step in the right direction. Using simple text files which contain the list of files (like the gpyi files already do today) isn't a new build system. It only offers the existing meta build systems (CMake, GYP, autotools, qmake) to use a common base. The remaining build systems can be ported to one of these systems or be adopted to use this file lists too. -- Patrick I suspect that we would quickly find that we would want some sort of support for conditionals and/or file inclusion in our simple text files, at which point you basically get a meta-meta-build system :). I don't actually think such a thing is that bad of an idea, but it's all in the details. I would like to find a solution where all of the ports were able to retain integration with their native build environments one way or another. -- Dirk
[webkit-dev] Removing ENABLE(WEB_INTENTS) code
Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber tha...@chromium.org wrote: On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel e...@webkit.org wrote: Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. If you build WebKit/chromium on Linux (i.e. Chromium/Linux and Chromium/Android), you're now using ninja. The Chromium Linux Release and Chromium Android Release build bots seem to be working fine. Admire the exciting build output: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio Let us know if anything is not working for you. (If you must use make, you can pass --no-ninja to update-webkit, and build-webkit will use make again. If you do this, please let me know why.) Chromium/Mac webkit builds now uses ninja by default too. The bot's build output is now a little more concise: http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio On my laptop, full builds are 10% faster and empty builds (the minimum time you need to wait for a build) are 30x as fast. If you still need xcodebuild, you can pass --no-ninja to update-webkit. Please let us know if and why you do this. Nico ps: Switching Chromium/Windows is blocked on http://crbug.com/169945, so it probably won't happen soon. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel e...@webkit.org wrote: Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. If you build WebKit/chromium on Linux (i.e. Chromium/Linux and Chromium/Android), you're now using ninja. The Chromium Linux Release and Chromium Android Release build bots seem to be working fine. Admire the exciting build output: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio Let us know if anything is not working for you. (If you must use make, you can pass --no-ninja to update-webkit, and build-webkit will use make again. If you do this, please let me know why.) Nico http://trac.webkit.org/changeset/137375 On Tue, Dec 11, 2012 at 3:33 PM, Eric Seidel e...@webkit.org wrote: This is now complete: http://trac.webkit.org/changeset/137371 I'm watching the bots. Please contact me if you have any trouble. Thank you all for your feedback. On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Eric is only suggesting changing update-webkit and build-webkit, which means that only the webkit.org bots would be affected. As long as the chromium.org canaries are still using chromium checkouts (and the native build systems), we'll still have coverage. Of course, your point is still valid for other scenarios where we don't have coverage of what we use on the official builds, but as Nico pointed out in a separate thread, so far this hasn't been a frequent problem. -- Dirk ___ 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] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. The idea is that gyp tries to write ninja files that behave as similar as possible to xcodebuild / devenv (or msbuild). In practice, this seems to work pretty well and it's rare that a ninja build works while xcodebuild doesn't -- well enough that all the chromium trybots use only ninja. Nico Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ 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] About text decoration wavy style implementation on Skia platform
On Mon, Nov 5, 2012 at 5:18 AM, Bruno Abinader brunoabina...@gmail.com wrote: Hi all, I am implementing the CSS3 text decoration style wavy for Skia platform [3], and I would like to know a few things (please let me know if this is not the right mailing list to ask this): - There is already a spelling line style implementation which mimics wavy style behavior, only with its own colors and theme. While Skia uses a custom, inline bitmap for rendering the red waves, other toolkits such as Cairo and Qt implements a function called drawErrorUnderline which renders the waves based on a given bounding rectangle. These are triggered by the drawLineForDocumentMarker function. - Individual implementations of the wavy style are popping up for each platform (ie. Qt [1] and Cairo [2] already have their implementations pending review). I see we can go both ways here: 1. Adapt the already implemented functions to support custom colors (as defined by -webkit-text-decoration-color, for example). While this looks easier on Qt and Cairo platforms, since drawErrorUnderline already gives everything we need, we would need to find a consensus on the custom bitmap usage for Skia platform. Of course, this would include updating the Qt [1] and Cairo [2] patches to support this approach. 2. Continue with individual implementations of the wavy style as we're doing now. I'm afraid this option would involve code duplication. IMO we should adopt first option, rename the drawErrorUnderline to drawWavyLine (as suggested by KyungTae Kim), and find a solution for the Skia custom bitmap approach. What do you guys think? The spelling underline on OS X is not a wavy line. If you end up changing the skia code, please make sure the chromium/mac spelling underline doesn't become a wavy line. Nico Links: [1] https://bugs.webkit.org/show_bug.cgi?id=93507 [2] https://bugs.webkit.org/show_bug.cgi?id=94110 [3] https://bugs.webkit.org/show_bug.cgi?id=93509 Best, -- Bruno de Oliveira Abinader Software Engineer @ basysKom GmbH WebKit committer / Nokia Certified Qt Specialist ___ 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] Pre-proposal: Adding a Coverity instance for WebKIt
On Tue, Sep 18, 2012 at 8:11 AM, James Hawkins jhawk...@chromium.org wrote: Hey folks, TL;DR - If you have opinions one way or another about having a Coverity instance available for WebKit developers, please respond to this message. I don't have an opinion, but: Coverity is a static analysis tool [1] which scans source code and reports defects in the code. We've been using Coverity to find defects in Chrome for a while now, and though there is sometimes a bit of subjectivity involved in the defect types (e.g. whether a return value should be checked), the signal is generally high. Off the top of my head, the following are the defects I spend most of my time fixing: * Uninitialized variables (including member variables). - Chrome has had at least 4 crash fixes in the past few months due to this defect (which were caught by Coverity). This sounds very useful. Do you know how this is done? If you have a class whose constructor calls a clear() function which sets all variables, will it warn about the constructor not initializing all members? If so, how do you suppress the warning in this case? (There was a thread on the clang mailing list on having a warning like this, and we couldn't come up with a good way to handle this case.) * Passing large parameters by value. - Generally a trivial fix. I don't have performance data to say what affect fixing these hash, but 'death by a thousand cuts' eh? I have seen at least three crashes in the last few months that were cause by changes to fix this warning (something that used to be a copied object became a dangling reference). I'm not sure this warning is worth it. * Forward/Reverse/I - Nulls. - Coverity is very good at understanding when a value is NULL and the tool will tell you which code paths are using a NULL value. * Tons of security issue-causing defects. I'd like to propose adding a Coverity instance for the WebKit community, but I want to make sure there's general support before writing up the detailed proposal. A few details: * Google will front the cost of the license (non-zero...very far from zero) and the infrastructure. * I'd leave it up to the WebKit leadership to decide who has access (most likely limited to WebKit committers for security purposes). The biggest rationale is to provide a strong defect signal for the entire WebKit community, which would directly impact the success of all WebKit-based projects. Coverity has provided free licenses for unsponsored (by larger corporations anyway) open-source projects; this has resulted in significant improvements [2] to the code bases of these projects, one of which I was directly involved with years ago (Wine). Let me know if you love the idea or hate it. Thanks, James [1] http://www.coverity.com/products/static-analysis.html [2] http://softwareintegrity.coverity.com/coverity-scan-2011-open-source-integrity-report-registration.html - registration required now :( ___ 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
[webkit-dev] ninja build available for chromium/mac, empty builds up to 20x as fast
Hi, we recently made the webkit/chromium/mac port buildable with ninja, a new build system focused on build speed (http://martine.github.com/ninja/). I don't have any numbers for webkit standalone builds, but in a chromium checkout ninja is 20x as fast as make on empty builds (1s instead of 20s), and 120x as fast as xcodebuild. Giving it a try is easy: Tools/Scrips/update-webkit --chromium --ninja Tools/Scripts/build-webkit --chromium The output will appear in out/Release (or out/Debug if you do a debug build). Nico ps: If anybody is doing standalone webkit/chromium/linux builds: It's very easy to make that work with ninja, too. pps: Build perf numbers for make vs ninja for chromium builds: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
Hi Adam, On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: Hi Elliot, It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing Support for Python 2.5
The chromium port still has a bot that runs tests (but doesn't build) on 10.5. Nico On Fri, Nov 4, 2011 at 3:20 PM, Eric Seidel e...@webkit.org wrote: Now that Apple has removed the Leopard build bot (and presumably stopped supporting WebKit on Leopard), all webkit platforms I know of have Python 2.6 or higher. My plan is to remove all of our 2.5 supporting code in the next week, requiring Python 2.6 or later for WebKit. Let me know if this will be an issue for you. Thanks! -eric ___ 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] [chromium] make build for chromium/mac (build twice as fast!) clang for chromium/linux
If you're now getting clang: error: unable to execute command: posix_spawn failed: Exec format error when ld is running, you're probably using Dave Levin's fake ld script without a she-bang line. Add #!/bin/bash to the first line of your /usr/bin/ld script in that case. (Or, if you're using the make build, ld is now serialized by default, so you can just mv /usr/bin/real-ld back to /usr/bin/ld.) Nico On Fri, Oct 21, 2011 at 1:37 PM, Nico Weber tha...@chromium.org wrote: Hi, if you don't work on the chromium webkit port for mac or linux, you can stop reading now. Three announcements about stand-alone webkit/chromium checkouts: 1.) Chromium/mac is now compiled with clang instead of gcc by default. This happens automatically, you don't need to do anything (on your local dev box, too). If you were wondering why compiler diagnostics are so much better all of a sudden, this is why. On my machine, this also brought the time for a full build from 23 minutes to 17 minutes. 2.) Chromium/mac can now optionally be built with make instead of xcodebuild. To do this, run update-webkit with GYP_GENERATORS set to make like this: GYP_GENERATORS=make Tools/Scripts/update-webkit --chromium build-webkit will then use make instead of xcodebuild, and new-run-webkit-tests will use the make-produced binary. On my machine, this reduced full build times from 17 minutes to 12 minutes (50% of the original gcc xcodebuild build time). If you build from within the Xcode IDE as opposed to on the command line, the speed-up might be a bit smaller. (To switch back to xcodebuild, run the command again without GYP_GENERATORS set, and delete the out/ folder.) (Note that this uses mac xcode_settings in the gyp files, not the linux-specific variables like cflags. This should hopefully make it fairly unlikely that the behavior of the make build and the xcode build diverge much.) 3.) As a side effect, the linux make build now supports clang as well. To use clang on linux, run Source/WebKit/chromium/tools/clang/scripts/update.sh # get clang, happens automatically on mac GYP_DEFINES=clang=1 Tools/Scripts/update-webkit --chromium and then build like you normally would (`build-webkit --chromium`). On linux, this mostly gets you better diagnostics, the build doesn't get all that much faster (it goes from 9:40 minutes with gcc4.4. to 8:30 minutes with clang on my linux box – only about 12% faster, and probably even less if you use a distributed build system). Let me know if you run into any issues. Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [chromium] make build for chromium/mac (build twice as fast!) clang for chromium/linux
Hi, if you don't work on the chromium webkit port for mac or linux, you can stop reading now. Three announcements about stand-alone webkit/chromium checkouts: 1.) Chromium/mac is now compiled with clang instead of gcc by default. This happens automatically, you don't need to do anything (on your local dev box, too). If you were wondering why compiler diagnostics are so much better all of a sudden, this is why. On my machine, this also brought the time for a full build from 23 minutes to 17 minutes. 2.) Chromium/mac can now optionally be built with make instead of xcodebuild. To do this, run update-webkit with GYP_GENERATORS set to make like this: GYP_GENERATORS=make Tools/Scripts/update-webkit --chromium build-webkit will then use make instead of xcodebuild, and new-run-webkit-tests will use the make-produced binary. On my machine, this reduced full build times from 17 minutes to 12 minutes (50% of the original gcc xcodebuild build time). If you build from within the Xcode IDE as opposed to on the command line, the speed-up might be a bit smaller. (To switch back to xcodebuild, run the command again without GYP_GENERATORS set, and delete the out/ folder.) (Note that this uses mac xcode_settings in the gyp files, not the linux-specific variables like cflags. This should hopefully make it fairly unlikely that the behavior of the make build and the xcode build diverge much.) 3.) As a side effect, the linux make build now supports clang as well. To use clang on linux, run Source/WebKit/chromium/tools/clang/scripts/update.sh # get clang, happens automatically on mac GYP_DEFINES=clang=1 Tools/Scripts/update-webkit --chromium and then build like you normally would (`build-webkit --chromium`). On linux, this mostly gets you better diagnostics, the build doesn't get all that much faster (it goes from 9:40 minutes with gcc4.4. to 8:30 minutes with clang on my linux box – only about 12% faster, and probably even less if you use a distributed build system). Let me know if you run into any issues. Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
Hi Eric, chromium's mac tryservers (which are similar to webkit's EWS) all build with svg disabled. Nico On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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] Git mirror out of sync?
Hi, git fetch origin git log origin/master suggests that the git mirror stopped syncing at r93166. Can someone kick it? Thanks, Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git mirror out of sync?
The first non-syned revision is http://trac.webkit.org/changeset/93167 , which is a huge directory move. This might just be slow to handle in git? On Wed, Aug 17, 2011 at 1:28 PM, David Levin le...@chromium.org wrote: From an irc conversation, it sounds like this is being worked on but git-svn just hangs, hard to tell why its broken dave On Wed, Aug 17, 2011 at 7:56 AM, Nico Weber tha...@chromium.org wrote: Hi, git fetch origin git log origin/master suggests that the git mirror stopped syncing at r93166. Can someone kick it? Thanks, Nico ___ 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] commit-queue platform musical chairs
I noticed that the commit-queue is a lot zippier now. Thanks! Nico On Wed, Jun 8, 2011 at 1:57 PM, Adam Barth aba...@webkit.org wrote: Update: The new commit-queue nodes run about 6x faster than the old nodes (wow). We're now fully switched over and have re-allocated the Mac Minis to the mac-ews, which should give us enough capacity to run the tests on Mac for every patch that's up for review. Adam On Sat, Jun 4, 2011 at 2:33 AM, Adam Barth aba...@webkit.org wrote: Up until now, we've been running the commit-queue on a cluster of Mac Minis, but building WebKit on these machines takes on the order of an hour and a half, making the commit-queue slow. EC2 offers much stronger machines, but unfortunately does not offer Mac OS X (likely due to licensing restrictions). We're experimenting with running the commit-queue on EC2 using the Chromium Linux port. Currently, we've got both kinds of nodes running so we can compare their effectiveness. I have a slight worry that most developers use the Mac port, and running the commit-queue in a different configuration might cause some trouble. If something bad happens, please let me know. We might need to add some more checks to make sure the commit-queue doesn't break Mac. Thanks for your patience, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Fri, Mar 25, 2011 at 10:59 AM, Maciej Stachowiak m...@apple.com wrote: In addition to your comments, I also find the gyp syntax somewhat unpleasant. In particular, in .gypi lists of files to compile, ever entry is double-quoted, comma-separated, line-separated, and then grouped in multiple levels of braces. This is noisier than any of our current formats except the XML-based ones. It seems like a newline-separated list, possibly indented, should be sufficient. For .gyp files themselves, I admit I don't have a clear understanding of what they are actually doing, so it's hard for me to say if the syntax they use is good or not. I think in general the trick of making the files essentially Python code is (presumably) handy for Python experts but not easy to read for anyone else. It's just python directory literals, which is virtually identical to json. Nico But I am assuming syntax-level things can be fixed once we have things working for more ports, and doesn't necessarily need to be a showstopper to initial adoption. Perhaps after successfully deploying gyp for one additional port, the right next steps are to make sure the experience is smooth and enjoyable for WebKit hackers, before propagating it further. Regards, Maciej On Mar 24, 2011, at 9:49 PM, Brent Fulgham wrote: Hi Dimitri, LONG screed follows... On Mar 24, 2011, at 9:24 AM, Dimitri Glazkov wrote: \With the gyp conversion at this stage, we now have a possible solution to this problem. Given that there aren't any other viable alternatives in the present, please consider the most productive way of contributing: filing well-formulated bugs, blocking bug 55018 (https://bugs.webkit.org/showdependencytree.cgi?id=55018hide_resolved=1). We can then discuss these specific problems and adjust the shape of the solution accordingly. While I applaud the idea of a unified build system, my own experience trying to get gyp working has been a uniformly frustrating experience. Imagine for a moment that rather than being a Chromium developer, long schooled in the use of gyp and the various build components needed to support it, you are a lowly external developer who just wishes to build WebKit. Out of curiosity, I took a stab at playing with gyp again this evening: 1. The top Google hit for gyp build system takes me to an exhaustive specification of the gyp input file syntax format. If I click on the Project Home link, I find no information on downloading or installing the system. Presumably I can download the source and somehow generate the tool. 2. If I go to the User Documentation page (http://code.google.com/p/gyp/wiki/GypUserDocumentation), I am instructed on how to draft my own gyp files to build things. But why would I care when I can't even try the software out on an existing project, like WebKit? Once I download the gyp sources and 'build' them using the included setup.py, it's not clear what to do with them: link:Source brent$ gyp . Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp ./gyp Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp help Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ I kind of hate gyp! Compare that to the native Xcode projects, CMake files, or normal GNU Makefiles. These other solutions almost always JUST WORK, because if you can build any software on your machine, you must have used one of these options. I don't use gyp for anything, I don't have it installed, and its not clear how to go about using it. Please don't further raise the barrier of entry to new WebKit developers by adding yet another obscure build requirement to the system. :-( Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt hy...@apple.com wrote: The only exception I would make to this rule is if all the call sites use variables and never pass in raw true or false. In that case there's no loss of readability, and whether you use an enum vs. a bool is irrelevant. I think in general the rule should be Keep your call sites readable, and convert to enums if you find that the call sites are becoming inscrutable. That rule makes sense to me. On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel e...@webkit.org wrote: Dave, I'm not sure I understand your exception. Could you give an example? I think what he means is that bool doSomething(); void doSomethingElse(bool); and the only case we always call doSomethingElse with a return value of some function or with a variable: doSomethingElse(doSomething()); doSomethingElse(shouldNotDoSomethingElse); etc... and we never call it with raw true/false: doSomethingElse(true) doSomethingElse(false) Out of curiosity, what do people think of doSomethingElse(/*paramName=*/true); when calling an existing function that takes a bool? Nico - 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] Accelerated 2D Tesselation Implementation
On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin cmar...@apple.com wrote: Hi Ken, It would help me, and I think many others, if we could have a discussion of how exactly your tessellation logic works and what it is intended to do. For instance, is the algorithm you're using based on Loop-Blinn? I'm a bit familiar with that algorithm and some of the problems it has with rendering this type of geometry. For instance, there are typically anti-aliasing artifacts at the points where the interior triangles touch the edges. These are described in section 5.1 of the paper and the authors added additional (and not well described) logic to solve the problem. If you could describe your algorithm a bit and show some expected results with typical cases, that would be really helpful. For those not familiar with Loop-Blinn, here is a link to their original paper, presented at Siggraph 2005: Resolution Independent Curve Rendering using Programmable Graphics ... It's a great algorithm for rendering resolution independent 2D objects using the GPU. It has potential to render both 2D shapes (as used in Canvas and SVG) and text glyphs. It's advantage is that once you generate the triangles for the shape, you can render the shape at any resolution. It's disadvantage is that the triangle generation is quite expensive, so mutating shapes can potentially be slower than a simpler resolution dependent tessellation. I think there's a variant of the algorithm that uses the stencil buffer polygon rendering method ( http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html ) instead of triangulation. The paper I think I read on that only covered quadratic splines, but maybe somehow has extended that method to cubic splines by now? Nico - ~Chris cmar...@apple.com ___ 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] Accelerated 2D Tesselation Implementation
On Fri, Aug 27, 2010 at 10:51 AM, Chris Marrin cmar...@apple.com wrote: On Aug 27, 2010, at 10:32 AM, Nico Weber wrote: On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin cmar...@apple.com wrote: Hi Ken, It would help me, and I think many others, if we could have a discussion of how exactly your tessellation logic works and what it is intended to do. For instance, is the algorithm you're using based on Loop-Blinn? I'm a bit familiar with that algorithm and some of the problems it has with rendering this type of geometry. For instance, there are typically anti-aliasing artifacts at the points where the interior triangles touch the edges. These are described in section 5.1 of the paper and the authors added additional (and not well described) logic to solve the problem. If you could describe your algorithm a bit and show some expected results with typical cases, that would be really helpful. For those not familiar with Loop-Blinn, here is a link to their original paper, presented at Siggraph 2005: Resolution Independent Curve Rendering using Programmable Graphics ... It's a great algorithm for rendering resolution independent 2D objects using the GPU. It has potential to render both 2D shapes (as used in Canvas and SVG) and text glyphs. It's advantage is that once you generate the triangles for the shape, you can render the shape at any resolution. It's disadvantage is that the triangle generation is quite expensive, so mutating shapes can potentially be slower than a simpler resolution dependent tessellation. I think there's a variant of the algorithm that uses the stencil buffer polygon rendering method ( http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html ) instead of triangulation. The paper I think I read on that only covered quadratic splines, but maybe somehow has extended that method to cubic splines by now? It looks like that technique deals with polygons, so as long as you convert the shape to a piecewise linear curve it seems like it can handle any curve form, right? What I linked is how to render polygons with the z buffer. http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html says: Recently, Kokojima et al. 2006 presented a variant on our approach for quadratic splines that used the stencil buffer to avoid triangulation. Their idea is to connect all points on the curve path and draw them as a triangle fan into the stencil buffer with the invert operator. Only pixels drawn an odd number of times will be nonzero, thus giving the correct image of concavities and holes. Next, they draw the curve segments, treating them all as convex quadratic elements. This will either add to or carve away a curved portion of the shape. A quad large enough to cover the extent of the stencil buffer is then drawn to the frame buffer with a stencil test. The result is the same as ours without triangulation or subdivision, and needing only one quadratic curve orientation. Furthermore, eliminating the triangulation steps makes high-performance rendering of dynamic curves possible. The disadvantage of their approach is that two passes over the curve data are needed. For static curves, they are trading performance for implementation overhead. Maybe someone extended Kokojima et al's work to cover cubic splines. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] style question for empty for loops
On Thu, Aug 26, 2010 at 11:49 AM, Darin Adler da...@apple.com wrote:
On Aug 26, 2010, at 11:35 AM, Chris Fleizach wrote:
for (...; ...; ...) { }
This seems OK.
for (...; ...; ...)
{ }
The above is definitely not allowed, because braces go on the line with the
for.
The other possibilities are:
C)
for (...)
;
D)
for (...) {
}
E)
for (...) {
// intentionally-empty loop body.
}
I would probably use (C) in code I was writing. This doesn’t come up much.
FWIW, clang warns about (C) but doesn't warn about the others (at
least on high warning levels).
Nico
-- Darin
___
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] Not enough space message when linking webkit (lots of free disk space)
Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm 11WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris ___ 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] CMake as a build system?
This is from an earlier thread on this issue on webkit-dev: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. Nico (I'm not involved with gyp at all, I just remembered that old thread) On Fri, Apr 16, 2010 at 6:45 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. Regards, Maciej ___ 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
