Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?
Den 2013-03-28 18:53:48 skrev Daniel Bratell brat...@opera.com: On a Xeon W3550 (quad 3.06GHz), with plenty of RAM but a spinning disk and Windows 7: webcore_dom: 58 seconds - 38 seconds (-35%) webcore_rendering: 106 seconds - 73 seconds (-30%) webcore_platform: 59 seconds - 34 seconds (-43%) (Yes, better than the 25% mentioned in the subject but this was on a different computer) I understand that this is not as interesting anymore since gyp is gone and Windows is a smaller platform than it used to be, but for the record, I've kept working on it in between other things and the total gain is about 7 minutes, which is better than the 25% estimate. This is in chromium land with the patch in http://pastebin.com/90vx4sep and the script in http://pastebin.com/WmzGY8zs. Both are pre-blink so they should look familiar, though they apply to gyp files which are gone. Neither have been cleaned up so they are a bit embarrassing but if someone wants to keep working on this in WebKit they might be a good starting point. To do in that case: * Port to the new build system for Windows. * Test compile a lot of platform and verify gains in Windows. * Integrate the idltopath.pm map generator into the build system. * Apply. /Daniel ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding __FILE__ and __LINE__ to CRASH() macro
Hi Darin, Any other concerns? May I file a bug provide the patch? BR On 15 April 2013 16:41, Arunprasad Rajkumar ararunpra...@gmail.com wrote: Forwarded conversation Subject: Adding __FILE__ and __LINE__ to CRASH() macro From: *Arunprasad Rajkumar* ararunpra...@gmail.com Date: 12 April 2013 15:29 To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Cc: arunpras...@nds.com (Hope this is the proper mailing list to ask, Sorry in-case of not) Hello Folks, In embedded platforms(mostly debugger is missing) it very difficult(for us) to debug the issues without proper prints in CRASH macro. Though it has WTFReportBacktrace(); due to some constraints we are not getting proper call stack information(debug build with -g is costlier for us) . So we are thinking to extend the functionality of WTFInvokeCrashHook by passing __FILE__ __LINE__ and printing it. Any suggestion? If you all agreed then I will create bug and submit a patch. Thanks BR -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- From: *Darin Adler* da...@apple.com Date: 12 April 2013 20:17 To: Arunprasad Rajkumar ararunpra...@gmail.com, arunpras...@nds.com Cc: WebKit Development webkit-dev@lists.webkit.org Is this for debug builds or for production builds? If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. If it is for production builds, then how do you debug other crashes? -- Darin -- From: *Arunprasad Rajkumar* ararunpra...@gmail.com Date: 13 April 2013 11:36 To: Darin Adler da...@apple.com Cc: arunpras...@nds.com, WebKit Development webkit-dev@lists.webkit.org Hi Darin, Is this for debug builds or for production builds? It is for production build. If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. So in-case of calling CRASH from ASSERT then it shouldn't print __FILE__ and __LINE__ right(because ASSERT prints all these)? If it is for production builds, then how do you debug other crashes? printf :( -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding __FILE__ and __LINE__ to CRASH() macro
On 04/16/2013 10:27 AM, Arunprasad Rajkumar wrote: Hi Darin, Any other concerns? May I file a bug provide the patch? BR For me this change doesn't seems to be too big or controversial, so I would say let's go for it ;) On 15 April 2013 16:41, Arunprasad Rajkumar ararunpra...@gmail.com mailto:ararunpra...@gmail.com wrote: Forwarded conversation Subject: *Adding __FILE__ and __LINE__ to CRASH() macro* From: *Arunprasad Rajkumar* ararunpra...@gmail.com mailto:ararunpra...@gmail.com Date: 12 April 2013 15:29 To: webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Cc: arunpras...@nds.com mailto:arunpras...@nds.com (Hope this is the proper mailing list to ask, Sorry in-case of not) Hello Folks, In embedded platforms(mostly debugger is missing) it very difficult(for us) to debug the issues without proper prints in CRASH macro. Though it has WTFReportBacktrace(); due to some constraints we are not getting proper call stack information(debug build with -g is costlier for us) . So we are thinking to extend the functionality of WTFInvokeCrashHook by passing __FILE__ __LINE__ and printing it. Any suggestion? If you all agreed then I will create bug and submit a patch. Thanks BR -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- From: *Darin Adler* da...@apple.com mailto:da...@apple.com Date: 12 April 2013 20:17 To: Arunprasad Rajkumar ararunpra...@gmail.com mailto:ararunpra...@gmail.com, arunpras...@nds.com mailto:arunpras...@nds.com Cc: WebKit Development webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Is this for debug builds or for production builds? If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. If it is for production builds, then how do you debug other crashes? -- Darin -- From: *Arunprasad Rajkumar* ararunpra...@gmail.com mailto:ararunpra...@gmail.com Date: 13 April 2013 11:36 To: Darin Adler da...@apple.com mailto:da...@apple.com Cc: arunpras...@nds.com mailto:arunpras...@nds.com, WebKit Development webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Hi Darin, Is this for debug builds or for production builds? It is for production build. If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. So in-case of calling CRASH from ASSERT then it shouldn't print __FILE__ and __LINE__ right(because ASSERT prints all these)? If it is for production builds, then how do you debug other crashes? printf :( -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ 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] mouseenter and mouseleave events
Hi webkit-dev I have recently uploaded a new patch to https://bugs.webkit.org/show_bug.cgi?id=18930 to implement mouseenter and mouseleave events. These events are part of DOM3 http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevents and supported by MSIE, Mozilla and pre-blink Opera. They are also listed as issues jQuery needs to work around in WebKit https://bugs.webkit.org/show_bug.cgi?id=110007 Previously they have not been implemented because they were not considered important, and could cause performance regression by issuing more events on every mouse-move that may not even be used by many websites. After I refactored hit-testing in the fall and especially moved the update of hover/active state out of hit-testing, it is now possible to dispatch these events where the hover state is updated, which makes the logic of dispatching mouseenter and mouseleave events correctly simple. It is also possible to only do one check for possible capturing listeners before issuing any mouseenter or mouseleave events for a mousemove. This is what the new patch does. It does incur an additional overhead by checking for the existence of capturing listeners, but the check is of lower magnitude than existing iterations over the tree, and should keep performance comparable, and is in all circumstances faster than issuing new events that fall for deaf ears. Are there more objections for the support of mouseenter and mouseleave events in WebKit? Best Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding __FILE__ and __LINE__ to CRASH() macro
Hi Balazs, For me this change doesn't seems to be too big or controversial, so I would say let's go for it ;) Thank u, I will submit a patch soon :) BR On 16 April 2013 14:31, Balazs Kelemen kbal...@webkit.org wrote: On 04/16/2013 10:27 AM, Arunprasad Rajkumar wrote: Hi Darin, Any other concerns? May I file a bug provide the patch? BR For me this change doesn't seems to be too big or controversial, so I would say let's go for it ;) On 15 April 2013 16:41, Arunprasad Rajkumar ararunpra...@gmail.comwrote: Forwarded conversation Subject: Adding __FILE__ and __LINE__ to CRASH() macro From: *Arunprasad Rajkumar* ararunpra...@gmail.com Date: 12 April 2013 15:29 To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Cc: arunpras...@nds.com (Hope this is the proper mailing list to ask, Sorry in-case of not) Hello Folks, In embedded platforms(mostly debugger is missing) it very difficult(for us) to debug the issues without proper prints in CRASH macro. Though it has WTFReportBacktrace(); due to some constraints we are not getting proper call stack information(debug build with -g is costlier for us) . So we are thinking to extend the functionality of WTFInvokeCrashHook by passing __FILE__ __LINE__ and printing it. Any suggestion? If you all agreed then I will create bug and submit a patch. Thanks BR -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- From: *Darin Adler* da...@apple.com Date: 12 April 2013 20:17 To: Arunprasad Rajkumar ararunpra...@gmail.com, arunpras...@nds.com Cc: WebKit Development webkit-dev@lists.webkit.org Is this for debug builds or for production builds? If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. If it is for production builds, then how do you debug other crashes? -- Darin -- From: *Arunprasad Rajkumar* ararunpra...@gmail.com Date: 13 April 2013 11:36 To: Darin Adler da...@apple.com Cc: arunpras...@nds.com, WebKit Development webkit-dev@lists.webkit.org Hi Darin, Is this for debug builds or for production builds? It is for production build. If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. So in-case of calling CRASH from ASSERT then it shouldn't print __FILE__ and __LINE__ right(because ASSERT prints all these)? If it is for production builds, then how do you debug other crashes? printf :( -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: committers.py is now contributors.json
As of http://trac.webkit.org/changeset/148527, the list of contributors, committers, and reviewers in committers.pyhttp://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py have been replaced by those of contributors.jsonhttp://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json in the same directory. Relevant documentation has been updated in the same changeset. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] mouseenter and mouseleave events
Hi On Tue, Apr 16, 2013 at 5:08 AM, Allan Sandfeld Jensen k...@carewolf.comwrote: I have recently uploaded a new patch to https://bugs.webkit.org/show_bug.cgi?id=18930 to implement mouseenter and mouseleave events. This sounds nice, but shouldn't you finish the support for image-rendering first? You added the code but it is not enabled anywhere. There is not one test covering the feature. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] mouseenter and mouseleave events
On Apr 16, 2013, at 5:08 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Hi webkit-dev I have recently uploaded a new patch to https://bugs.webkit.org/show_bug.cgi?id=18930 to implement mouseenter and mouseleave events. These events are part of DOM3 http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevents and supported by MSIE, Mozilla and pre-blink Opera. They are also listed as issues jQuery needs to work around in WebKit https://bugs.webkit.org/show_bug.cgi?id=110007 Previously they have not been implemented because they were not considered important, and could cause performance regression by issuing more events on every mouse-move that may not even be used by many websites. After I refactored hit-testing in the fall and especially moved the update of hover/active state out of hit-testing, it is now possible to dispatch these events where the hover state is updated, which makes the logic of dispatching mouseenter and mouseleave events correctly simple. It is also possible to only do one check for possible capturing listeners before issuing any mouseenter or mouseleave events for a mousemove. This is what the new patch does. It does incur an additional overhead by checking for the existence of capturing listeners, but the check is of lower magnitude than existing iterations over the tree, and should keep performance comparable, and is in all circumstances faster than issuing new events that fall for deaf ears. Are there more objections for the support of mouseenter and mouseleave events in WebKit? Seems like a reasonable feature to add. - Maciej ___ 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?
Hi Daniel, I'm afraid I don't quite understand the nature of the change you are proposing: 1. Is it sufficient to supply the full path to the include files (e.g., change Foo.h to WebCore/html/Foo.h) to achieve these gains? 2. ... or ... is it sufficient to copy all header files to a common include target path (e.g., $(BuildDir)/include) to achieve these gains? I understand that in either case, we would want to remove the various compiler include path directives so that there are fewer places for it to search. Is something else needed? Thanks, -Brent On Tue, Apr 16, 2013 at 12:59 AM, Daniel Bratell brat...@opera.com wrote: Den 2013-03-28 18:53:48 skrev Daniel Bratell brat...@opera.com: On a Xeon W3550 (quad 3.06GHz), with plenty of RAM but a spinning disk and Windows 7: webcore_dom: 58 seconds - 38 seconds (-35%) webcore_rendering: 106 seconds - 73 seconds (-30%) webcore_platform: 59 seconds - 34 seconds (-43%) (Yes, better than the 25% mentioned in the subject but this was on a different computer) I understand that this is not as interesting anymore since gyp is gone and Windows is a smaller platform than it used to be, but for the record, I've kept working on it in between other things and the total gain is about 7 minutes, which is better than the 25% estimate. This is in chromium land with the patch in http://pastebin.com/90vx4sepand the script in http://pastebin.com/WmzGY8zs. Both are pre-blink so they should look familiar, though they apply to gyp files which are gone. Neither have been cleaned up so they are a bit embarrassing but if someone wants to keep working on this in WebKit they might be a good starting point. To do in that case: * Port to the new build system for Windows. * Test compile a lot of platform and verify gains in Windows. * Integrate the idltopath.pm map generator into the build system. * Apply. /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] Compiling WebKit up to 25% faster in Windows?
On Tue, Apr 16, 2013 at 3:58 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Daniel, I'm afraid I don't quite understand the nature of the change you are proposing: 1. Is it sufficient to supply the full path to the include files (e.g., change Foo.h to WebCore/html/Foo.h) to achieve these gains? 2. ... or ... is it sufficient to copy all header files to a common include target path (e.g., $(BuildDir)/include) to achieve these gains? I understand that in either case, we would want to remove the various compiler include path directives so that there are fewer places for it to search. I believe he's proposing the former -- (1) -- along with the necessary changes to all the code generation scripts to do the right thing. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: committers.py is now contributors.json
Changed the link from committers.py to contributors.json in https://trac.webkit.org/wiki/WebKit%20Team :) On Wed, Apr 17, 2013 at 4:05 AM, Ryosuke Niwa rn...@webkit.org wrote: As of http://trac.webkit.org/changeset/148527, the list of contributors, committers, and reviewers in committers.py have been replaced by those of contributors.json in the same directory. Relevant documentation has been updated in the same changeset. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- . The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mailer and delete this message and its attachments, if any. Thank you for your cooperation. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
